Definitelytyped: ramda fails on typescript@next with "Type instantiation is excessively deep"

[sandersn]

Error in ramda
Error: /home/vsts/work/1/s/DefinitelyTyped/types/ramda/ramda-tests.ts:78:50
ERROR: 78:50    expect  TypeScript@next compile error: 
Type instantiation is excessively deep and possibly infinite.
ERROR: 79:39    expect  TypeScript@next compile error: 
Type instantiation is excessively deep and possibly infinite.
ERROR: 2700:36  expect  TypeScript@next compile error: 
Type instantiation is excessively deep and possibly infinite.

    at /home/vsts/work/1/s/node_modules/dtslint/bin/index.js:190:19
    at Generator.next (<anonymous>)
    at fulfilled (/home/vsts/work/1/s/node_modules/dtslint/bin/index.js:5:58)

from:

    const x3: (c: number, d: number) => number = R.curry(addFourNumbers)(1)(2);
    const x4: (d: number) => number = R.curry(addFourNumbers)(1)(2)(3);
    const c: (a: any[]) => any[] = R.symmetricDifferenceWith(eqA)(l1); // => [{a: 1}, {a: 2}, {a: 5}, {a: 6}]

@pirix-gh this is likely because your efforts to avoid the conditional instantiation limit no longer work after microsoft/typescript#31545

For now I'm going to comment out the three failing tests.

[sandersn]

Pinging other owners in case anybody else wants to take a look.

@donnut @mdekrey @mrdziuban @sbking @afharo @teves-castro @1M0reBug @hojberg @samsonkeung @angeloocana @raynerd @googol @moshensky @ethanresnick @leighman @deftomat @deptno @blimusiek @biern @rayhaneh @rgm @drewwyatt @jottenlips @minitesh @krantisinh @pirix-gh @brekk @nemo108 @jituanlin

[millsp]

Looking into it :mag:

[sandersn]

PR is at #37839

[millsp]

Hi @sandersn,

import {F} from 'ts-toolbelt'

function addFourNumbers(a: number, b: number, c: number, d: number): number {
     return a + b + c + d;
}

// this fails
const test0: (d: number) => number = R.curry(addFourNumbers)(1)(2)(3);

// this fails
const test1: F.Curry<(d: number) => number> = R.curry(addFourNumbers)(1)(2)(3);

// this works
const test2 = R.curry(addFourNumbers)(1)(2)(3);

This is what I've noticed so far, maybe you can shed some light on this? Shouldn't it fail in all cases, or not fail at all (consistency-wise)?

I'm inspecting atm the condition that terminates the Curry type, which might be the culprit.

[sandersn]

I'll defer to @weswigham for this one, since he's worked a lot with conditional types recently.

[millsp]

@sandersn It's on the way to be fixed. My bad! Historically, I used to have lots of <x> extends infer <X>, to force TS to do lazy loading, but I've removed them in favor of immediately indexed types. However, they still remain on recursive types and are still working :yum:

In this case, immediately indexed types caused TS to evaluate a type that got very huge and this is where the problem came from, causing a snowball effect when combined with other types (like Curry).
So I've (exceptionally) forced TS not to evaluate this (non-recursive) type, and it solved the problem. I'd like to emphasize on the fact that the Curry type (with Placeholder analysis) is extremely complex => It would be nice that TS evaluates a type only after it received its generic params (lazy loading).

https://github.com/pirix-gh/ts-toolbelt/commit/62b783ee5f8e277f170455f0260d7371df6a2694

Cheers

[sandersn]

Would you be able to open a PR on DT that updates ramda's dependency on ts-toolbelt and then re-enables the three test cases I commented out?

[millsp]

Yes, I'm busy with it

[millsp]

Hey @sandersn, just a follow up. I've undone what I did above. The problem was indeed due to an increased complexity that was caused by a double trigger of GapsOf<T, Parameters<F>> which is now inferred into a type (once, only). So there is no more exceptions with the infer, back to normal.

And I am going to integrate ramda's tests to my CI test flow. And will integrate any other DT dependents in the future. So there won't be breaking changes from my side :smile_cat: