Skip to content

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

Description

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:

Activity

  1. sandersn commented on Aug 29, 2019

    @sandersn
    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.

  2. weswigham commented on Aug 29, 2019

    @weswigham
    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.

  3. added
    BugA bug in TypeScript
    Domain: Indexed Access TypesThe issue relates to accessing subtypes via index access
    and removed
    Needs InvestigationThis issue needs a team member to investigate its status.
    on Aug 29, 2019
  4. zetoke commented on Aug 29, 2019

    @zetoke

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

    typeorm/typeorm#4662

  5. nappy commented on Sep 2, 2019

    @nappy

    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.

  6. weswigham commented on Sep 2, 2019

    @weswigham
    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.

  7. sam-hunt commented on Sep 2, 2019

    @sam-hunt

    This fixes the issue for me thanks.

  8. karol-majewski commented on Sep 2, 2019

    @karol-majewski

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

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

  9. zetoke commented on Sep 3, 2019

    @zetoke

    Wesley Wigham (@weswigham) It fixes all the problems for me. Huge thanks!

  10. andrew8er commented on Sep 3, 2019

    @andrew8er

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

  11. nappy commented on Sep 3, 2019

    @nappy

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

  12. enzigma-ajinkya-kumbhar commented on Sep 5, 2019

    @enzigma-ajinkya-kumbhar

    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<...>; }'.
    
  13. enzigma-ajinkya-kumbhar commented on Sep 5, 2019

    @enzigma-ajinkya-kumbhar

    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.

  14. luketanner commented on Sep 6, 2019

    @luketanner

    Wesley Wigham (@weswigham) That indeed fixed it for me! Thanks!

  15. DanielRosenwasser commented on Sep 9, 2019

    @DanielRosenwasser
    Member

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

  16. sam-hunt commented on Sep 9, 2019

    @sam-hunt

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

  17. OliverJAsh commented on Sep 10, 2019

    @OliverJAsh
    ContributorAuthor

    Daniel Rosenwasser (@DanielRosenwasser) Works for me now in typescript@3.6.3-insiders.20190909. Thanks!

  18. nappy commented on Sep 10, 2019

    @nappy

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

  19. ljosberinn commented on Sep 11, 2019

    @ljosberinn

    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.

  20. locked as resolved and limited conversation to collaborators on Oct 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

BugA bug in TypeScriptDomain: Indexed Access TypesThe issue relates to accessing subtypes via index accessDomain: Mapped TypesThe issue relates to mapped types

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions