Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
OliverJAsh opened this issue Aug 29, 2019 · 18 comments · Fixed by #33144
Assignees
Labels
Bug A bug in TypeScript Domain: Indexed Access Types The issue relates to accessing subtypes via index access Domain: Mapped Types The issue relates to mapped types

Comments

@OliverJAsh
Copy link
Contributor

OliverJAsh commented Aug 29, 2019

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
Copy link
Member

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
Copy link
Member

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 weswigham added Bug A bug in TypeScript Domain: Indexed Access Types The issue relates to accessing subtypes via index access Domain: Mapped Types The issue relates to mapped types and removed Needs Investigation This issue needs a team member to investigate its status. labels Aug 29, 2019
@zetoke
Copy link

zetoke commented Aug 29, 2019

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

typeorm/typeorm#4662

@nappy
Copy link

nappy commented Sep 2, 2019

Uprading from 3.5.3 to 3.6.2 gives me this error:

error TS2321: Excessive stack depth comparing types 'Function' and '{ [K in keyof T]?: Morphism<T[K], T[K]> | { [K in keyof T[K]]?: Morphism<T[K][K], T[K][K]> | { [K in keyof T[K][K]]?: Morphism<T[K][K][K], T[K][K][K]> | { [K in keyof T[K][K][K]]?: Morphism<T[K][K][K][K], T[K][K][K][K]> | { [K in keyof T[K][K][K][K]]?: Morphism<T[K][K][K][K][K], T[K][K][K][K][K]> | { [K in keyof T[K][K][K][K][K]]?: Morphism<T[K][K][K][K][K][K], T[K][K][K][K][K][K]> | { [K in keyof T[K][K][K][K][K][K]]?: Morphism<T[K][K][K][K][K][K][K], T[K][K][K][K][K][K][K]> | { [K in keyof T[K][K][K][K][K][K][K]]?: Morphism<T[K][K][K][K][K][K][K][K], T[K][K][K][K][K][K][K][K]> | { [K in keyof T[K][K][K][K][K][K][K][K]]?: Morphism<T[K][K][K][K][K][K][K][K][K], T[K][K][K][K][K][K][K][K][K]> | { [K in keyof T[K][K][K][K][K][K][K][K][K]]?: Morphism<T[K][K][K][K][K][K][K][K][K][K], T[K][K][K][K][K][K][K][K][K][K]> | { [K in keyof T[K][K][K][K][K][K][K][K][K][K]]?: Morphism<T[K][K][K][K][K][K][K][K][K][K][K], T[K][K][K][K][K][K][K][K][K][K][K]> | any | undefined; } | undefined; } | undefined; } | undefined; } | undefined; } | undefined; } | undefined; } | undefined; } | undefined; } | undefined; } | undefined; }'.

Unfortunately it does not give me any hint on which dependency is causing this, but all of them are on the latest version available at time of this posting.

@weswigham
Copy link
Member

If anyone having trouble with this could try out the build (that will soon be posted) in #33144 (comment) 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.

@sam-hunt
Copy link

sam-hunt commented Sep 2, 2019

This fixes the issue for me thanks.

@karol-majewski
Copy link

This fixed it for me (or rather for us @OliverJAsh) as well.

(Just a side note: @weswigham I think you meant this comment since that's the one with installation instructions.)

@zetoke
Copy link

zetoke commented Sep 3, 2019

@weswigham It fixes all the problems for me. Huge thanks!

@andrew8er
Copy link

andrew8er commented Sep 3, 2019

I was affected by typeorm/typeorm#4662 and this fixed it for me, thanks!

@nappy
Copy link

nappy commented Sep 3, 2019

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

@enzigma-ajinkya-kumbhar
Copy link

I am facing the issue with typeorm@0.2.16 with typescript@latest.
I have even tried downgrading the typescript version to 3.5.2 and 3.5.3 still it did not work for me.

Following is the error for your reference

error TS2321: Excessive stack depth comparing types 'MongoRepository<Entity>' and 'Repository<Entity>'.
node_modules/typeorm/repository/MongoRepository.d.ts(12,22): error TS2589: Type instantiation is excessively deep and possibly infinite.
node_modules/typeorm/repository/MongoRepository.d.ts(45,5): error TS2321: Excessive stack depth comparing types '(optionsOrConditions?: string | number | Date | ObjectID | FindOneOptions<Entity> | Partial<Entity>, maybeOptions?: FindOneOptions<Entity>) => Promise<Entity>' and '{ (id?: string | number | Date | ObjectID, options?: FindOneOptions<Entity>): Promise<Entity>; (options?: FindOneOptions<Entity>): Promise<Entity>; (conditions?: FindConditions<Entity>, options?: FindOneOptions<...>): Promise<...>; }'.

@enzigma-ajinkya-kumbhar
Copy link

I have got the solution.This 33259 solution worked for the time being and we need the proper solution which will support the latest versions of the typescript.

@luketanner
Copy link

@weswigham That indeed fixed it for me! Thanks!

@DanielRosenwasser
Copy link
Member

Can you all try out typescript@3.6.3-insiders.20190909 on npm and verify whether that works?

@sam-hunt
Copy link

sam-hunt commented Sep 9, 2019

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

@OliverJAsh
Copy link
Contributor Author

@DanielRosenwasser Works for me now in typescript@3.6.3-insiders.20190909. Thanks!

@nappy
Copy link

nappy commented Sep 10, 2019

Yes, 3.6.3-insiders.20190909 works for me too.

@ljosberinn
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Domain: Indexed Access Types The issue relates to accessing subtypes via index access Domain: Mapped Types The issue relates to mapped types
Projects
None yet
Development

Successfully merging a pull request may close this issue.