TypeScript: 3.6 regression: `error TS2321: Excessive stack depth comparing types 'Function' and 'Function'.`

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:

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 11
Comments: 18 (5 by maintainers)

Most upvoted comments

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

https://github.com/typeorm/typeorm/issues/4662

zetoke on Aug 29, 2019

If anyone having trouble with this could try out the build (that will soon be posted) in https://github.com/microsoft/TypeScript/pull/33144#issuecomment-527235862 and report back/updoot if it fixed your problem, that’d be great. Based on what I’ve been given, I believe it should, but more input is always appreciated.

weswigham on Sep 2, 2019

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.

weswigham on Aug 29, 2019

Neither the 3.6.3 insiders nor the 3.7.0 insiders currently fix this issue for me in this repo - it however might be rbx typings, unsure about that, x-posting to rbx too.

ljosberinn on Sep 11, 2019

Works for me thanks. Same successful compilation result as in 3.7.0-insiders.20190902, linked above by @weswigham.

sam-hunt on Sep 9, 2019

I can confirm, 3.7.0-insiders.20190902 fixes the issue I posted above.

nappy on Sep 3, 2019