3.6 regression: `error TS2321: Excessive stack depth comparing types 'Function<?>' and 'Function<?>'.`

[OliverJAsh]

TypeScript Version: 3.6.2

Search Terms: excessive stack depth regression comparing types function lodash

Code

tsconfig.json:

{
    "compilerOptions": {
        "allowSyntheticDefaultImports": true,

        // Disable this and you get more information about the errors?
        "strictNullChecks": true
    }
}

package.json:

{
  "dependencies": {
    "@types/lodash": "4.14.129",
    "typescript": "3.6.2"
  }
}

main.ts:

import negate from 'lodash/negate';

Expected behavior:

Compiles

Actual behavior:

$ tsc
error TS2321: Excessive stack depth comparing types 'Function<?>' and 'Function<?>'.


Found 1 error.

This error doesn't give any helpful information for debugging.

Upgrading @types/lodash to the latest version (4.14.138 at time of writing) seems to fix the issue.

If we disable strictNullChecks, we get a bit more information about the error (for some reason?):

$ tsc
error TS2321: Excessive stack depth comparing types 'Function<?>' and 'Function<?>'.

node_modules/@types/lodash/ts3.1/common/common.d.ts:194:15 - error TS2589: Type instantiation is excessively deep and possibly infinite.

194     interface Object<T> extends LoDashImplicitWrapper<T> {
                  ~~~~~~


Found 2 errors.

This did not error in TS 3.5, so I think it's a regression?

Playground Link:

Related Issues:

[sandersn]

Conditional types now evaluate more eagerly than before, which means that the assignability cutoff gets hit more. I think this is likely by design, but we should investigate before closing.

[weswigham]

Actually, this has zero to do with conditional types (which iirc we didn't actually change all that much this release), but everything to do with mapped types and indexed accesses. Specifically, readonly ListIteratee<?>[] vs Many<ListIteratee<?>>, because it's comparison target also expands forever - Many<ListIteratee<?>> becomes PartialDeep<?> which becomes PartialDeep<?[P]> which expands to PartialDeep<?[P][P]> and so on. We blow the comparison stack limit once we start comparing PartialDeep<?[P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P][P]> with readonly ListIteratee<?>[][keyof ? & number & P][keyof ?[P] & keyof readonly ListIteratee<?>[][keyof ? & number & P] & P][keyof ?[P][P] & keyof readonly ListIteratee<?>[][keyof ? & number & P][keyof ?[P] & ... 1 more ... & P] & P][keyof ?[P][P][P] & ... 1 more ... & P][keyof ?[P][P][P][P] & ... 1 more ... & P][keyof.... For reference, the other side expands readonly ListIteratee<?>[] -> readonly ListIteratee<?>[][keyof ? & number & P] -> readonly ListIteratee<?>[][keyof ? & number & P][keyof ?[P] & keyof readonly ListIteratee<?>[][keyof ? & number & P] & P].

We probably introduced this in #32071. I think this is fixable with existing mechanisms - we already recognize that the PartialDeep type probably infinitely expands - the ListIteratee-based type expansion currently avoids that check, as it does not have a symbol with which for us to track how often we've seen derivations of it. I think might be able to modify the deeply nested check to catch it, or at least bail even if only one side is measured as superduperdeep. Yes, that is a highly technical term.

[zetoke]

+1 issue with typeorm in 3.6.2. Rolling back to 3.5 helps.

typeorm/typeorm#4662