Repository navigation
3.6 regression: error TS2321: Excessive stack depth comparing types 'Function<?>' and 'Function<?>'. #33132
Description
Activity
sandersn commented
on Aug 29, 2019 MemberMore actionsConditional 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.
- addedNeeds InvestigationThis issue needs a team member to investigate its status.This issue needs a team member to investigate its status.
on Aug 29, 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<?>[]vsMany<ListIteratee<?>>, because it's comparison target also expands forever -Many<ListIteratee<?>>becomesPartialDeep<?>which becomesPartialDeep<?[P]>which expands toPartialDeep<?[P][P]>and so on. We blow the comparison stack limit once we start comparingPartialDeep<?[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]>withreadonly 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 expandsreadonly 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
PartialDeeptype probably infinitely expands - theListIteratee-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.Reacted by Oliver Joseph Ash, AnyhowStep, Karol Majewski, Leo Y. Li, Titian Cernicova-Dragomir and Slava- addedBugA bug in TypeScriptA bug in TypeScriptDomain: Indexed Access TypesThe issue relates to accessing subtypes via index accessThe issue relates to accessing subtypes via index accessDomain: Mapped TypesThe issue relates to mapped typesThe issue relates to mapped typesand removedNeeds InvestigationThis issue needs a team member to investigate its status.This issue needs a team member to investigate its status.
on Aug 29, 2019 +1 issue with typeorm in 3.6.2. Rolling back to 3.5 helps.
Reacted by AnyhowStep, Marat Dyatko, Andrew Eddie, Leo Y. Li, A-J Roos, James and Bartłomiej KorpusUprading 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.
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.
Reacted by Luke TannerReacted by Sam Hunt, André Wachter, James, Dmitry Ermakov and Luke TannerThis fixes the issue for me thanks.
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.)
Wesley Wigham (@weswigham) It fixes all the problems for me. Huge thanks!
I was affected by typeorm/typeorm#4662 and this fixed it for me, thanks!
I can confirm, 3.7.0-insiders.20190902 fixes the issue I posted above.
Reacted by b3n01tI 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<...>; }'.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.
Wesley Wigham (@weswigham) That indeed fixed it for me! Thanks!
DanielRosenwasser commented
on Sep 9, 2019 MemberMore actionsCan you all try out
typescript@3.6.3-insiders.20190909on npm and verify whether that works?Works for me thanks. Same successful compilation result as in 3.7.0-insiders.20190902, linked above by Wesley Wigham (@weswigham).
Reacted by Daniel RosenwasserOliverJAsh commented
on Sep 10, 2019 ContributorAuthorMore actionsDaniel Rosenwasser (@DanielRosenwasser) Works for me now in
typescript@3.6.3-insiders.20190909. Thanks!Yes, 3.6.3-insiders.20190909 works for me too.
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.
Reacted by Ben van de Sande and Ali Bey- locked as resolved and limited conversation to collaborators
on Oct 21, 2025
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:Expected behavior:
Compiles
Actual behavior:
This error doesn't give any helpful information for debugging.
Upgrading
@types/lodashto 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?):This did not error in TS 3.5, so I think it's a regression?
Playground Link:
Related Issues: