Excessive Stack Depth from DeepPartial/RecursivePartial in 2.7.x #21592

kevinbeal · 2018-02-03T00:03:53Z

Search Terms:
"excessive depth"
"generic partial"

Code

const fn = <T>(arg: T) => {
    ((arg2: RecursivePartial<T>) => {
        // ...
    })(arg); // <-- here
};

type RecursivePartial<T> = {
    [P in keyof T]?: RecursivePartial<T[P]>;
};

Expected behavior:
Comparing a generic with a partial of that generic working without errors.

Actual behavior:
Getting "Excessive stack depth comparing types 'T' and 'RecursivePartial'." since upgrading to 2.7.x. (Also errors in 2.8.x). Working in 2.6.1.

Playground Link:
https://www.typescriptlang.org/play/index.html#src=class%20Greeter%20%7B%0D%0A%20%20%20%20greeting%3A%20RecursivePartial%3Cstring%3E%3B%0D%0A%20%20%20%20constructor(message%3A%20string)%20%7B%0D%0A%20%20%20%20%20%20%20%20this.greeting%20%3D%20message%3B%0D%0A%20%20%20%20%7D%0D%0A%20%20%20%20greet()%20%7B%0D%0A%20%20%20%20%20%20%20%20return%20%22Hello%2C%20%22%20%2B%20this.greeting%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0Alet%20greeter%20%3D%20new%20Greeter(%22world%22)%3B%0D%0A%0D%0Alet%20button%20%3D%20document.createElement('button')%3B%0D%0Abutton.textContent%20%3D%20%22Say%20Hello%22%3B%0D%0Abutton.onclick%20%3D%20function()%20%7B%0D%0A%20%20%20%20alert(greeter.greet())%3B%0D%0A%7D%0D%0A%0D%0Adocument.body.appendChild(button)%3B%0D%0A%0D%0Aconst%20fn%20%3D%20%3CT%3E(arg%3A%20T)%20%3D%3E%20%7B%0D%0A%20%20%20%20((arg2%3A%20RecursivePartial%3CT%3E)%20%3D%3E%20%7B%0D%0A%20%20%20%20%20%20%20%20%2F%2F%0D%0A%20%20%20%20%7D)(arg)%3B%0D%0A%7D%3B%0D%0A%0D%0Atype%20RecursivePartial%3CT%3E%20%3D%20%7B%0D%0A%20%20%20%20%5BP%20in%20keyof%20T%5D%3F%3A%20RecursivePartial%3CT%5BP%5D%3E%3B%0D%0A%7D%3B

Related Issues:
None?

Conaclos · 2018-03-03T19:27:08Z

I got the same code with the next code:

type SafeAny <T> = {
    [k in keyof T]?: SafeAny<T[k]>
} | boolean | number | string | symbol | null | undefined

type DataValidator <T> = {
    [k in keyof T]?: (v: SafeAny<T[k]>) => v is T[k]
}

The following error is reported:

error TS2321: Excessive stack depth comparing types 'T[k]' and 'SafeAny<T[k]>'.

@kevinbeal
Your playground link is wrong (you need to hit "share" before copying the link).

kevinbeal · 2018-03-05T16:48:51Z

@Conaclos In what sense exactly is the link wrong? I did hit "share". It wouldn't be a really long URL with url encoded typescript in the URL if I hadn't. Are you not seeing the issue when you click the link?

Conaclos · 2018-03-05T18:51:30Z

@kevinbeal
Sorry, I expected the same code than the one posted here...

sandersn · 2018-03-14T17:55:30Z

From bisecting, the bad commit is part of #19564.

Recursive mapped types usually lead to the error "excess stack depth comparing types" because of a new type relation rule added in #19564 which says that "A source type T is related to a target type { [P in keyof T]: X } if T[P] is related to X". Unfortunately, with self-recursive mapped types like ```ts D<T> = { [P in keyof T]: D<T[P]> } ``` we get infinite recursion when trying to assign a type parameter T to D<T>, as T[P] is compared to D<T[P]>, T[P][P] is compared to D<T[P][P]>, and so on. We can avoid many of these infinite recursions by replacing occurrences of D in the template type with its type argument. This works because mapped types will completely cover the tree, so checking assignability of the top level implies that checking of lower level would succeed, even if there are infinitely many levels. For example: ```ts D<T> = { [P in keyof T]: D<T[P]> | undefined } <T>(t: T, dt: D<T>) => { dt = t } ``` would previously check that `T[P]` is assignable to `D<T[P]> | undefined`. Now, after replacement, it checks that `T[P]` is assignable to `T[P] | undefined`. This implementation suffers from 3 limitations: 1. I use aliasSymbol to detect whether a type reference is a self-recursive one. This only works when the mapped type is at the top level of a type alias. 2. Not all instances of D<T> are replaced with T, just those in intersections and unions. I think this covers almost all uses. 3. This doesn't fix #21048, which tries to assign an "off-by-one" partial-deep type to itself. Mostly fixes #21592. One repro there has a type alias to a union, and a mapped type is a member of the union. But this can be split into two aliases: ```ts type SafeAnyMap<T> = { [K in keyof T]?: SafeAny<T[K] }; type SafeAny<T> = SafeAnyMap<T> | boolean | string | symbol | number | null | undefined; ```

chirdeeptomar · 2018-06-02T12:32:49Z

I am using TypeScript 2.9.1 and still the same issue.

rafaelbatistamarcilio · 2018-06-02T12:37:53Z

@chirdeeptomar this issue was assigned to the 3.0 milestone

hswhite33 · 2019-06-20T04:30:46Z

Running into the same issue with typescript@3.5.1 and redux@4.0.1. Redux also provides a DeepPartial type.

Example:

function foo<S>(reducer: Redux.Reducer<S>, initialState: S) {
	const middleware: Redux.Middleware<{}, S>[] = [];
	const compose = window['__REDUX_DEVTOOLS_EXTENSION_COMPOSE__'] || Redux.compose;
	return Redux.createStore(reducer, initialState, compose(Redux.applyMiddleware(...middleware)));
}

This actually results in excessive stack depth on both the second and third params of createStore:

The second fails trying to compare S with DeepPartial<S>, and can be resolved by passing initialState as unknown as Redux.DeepPartial<S>
The third fails trying to compare any with DeepPartial<S> and can be resolved by casting compose as typeof Redux.compose

This has gotten worse in one of the more recent TypeScript versions; with typescript@3.1.6 I only needed to add as any to workaround the second parameter, and no workaround was necessary for the third.

Seems like this is a difficult problem on TypeScript's end so hopefully this workaround is useful to someone else in the meantime... Is this something I should be raising with the Redux maintainers?

sandersn · 2019-06-20T15:38:21Z

@hswhite33 Yes, the Redux maintainers should first consider whether they need the additional type safety or inference information that comes from DeepPartial. Redux users probably don't rely on it that much, actually.

If they want to keep it, they can use the workaround above, although it might break in future Typescript versions.

…t with typeorm. fixes error TS2321: Excessive stack depth comparing types 'any' and 'FindConditions<T>' More context on the issue: microsoft/TypeScript#21592 (comment) Related PR: typeorm#4470

…#35848) * Remove PartialDeep from lodash, replace w/Partial Fixes the most common occurrence of microsoft/TypeScript#21592. I don't think anybody uses the full capability of `PartialDeep` as a parameter, and it doesn't really make sense as the return type of `pick`. * Use PartialObject name instead of GlobalPartial

Yaojian · 2019-08-15T18:22:29Z

I bet a $ that we will see a message: sandersn (or whoever) modified the milestones: TypeScript 3.5.0, TypeScript 3.6.0 some day. 😿

I won but disappointed. 😭

Now my questions is: Will it be moved to 3.7.0 😿 ? Should I bet 10$ ?

error TS2321: Excessive stack depth comparing types 'DataObject<?>' and 'DataObject<?>'. See microsoft/TypeScript#21592

alfaproject · 2019-08-28T20:33:42Z

Just got hit by this in TS 3.6.2 which Renovate bot just attempted to update to and our pipeline failed. ):

It's not even our own code. It comes from one of the libraries that we use:

error TS2321: Excessive stack depth comparing types 'ElemMatch<?>' and 'ElemMatch<?>'.
error TS2321: Excessive stack depth comparing types 'InternalQuery<?>' and 'InternalQuery<?>'.
error TS2321: Excessive stack depth comparing types 'SiftQuery<?>' and 'SiftQuery<?>'.

https://github.com/crcn/sift.js/blob/ef8c5ca2e4b4277cf79085dd4168dbbe58ea4869/index.d.ts

error TS2321: Excessive stack depth comparing types 'DataObject<?>' and 'DataObject<?>'. See microsoft/TypeScript#21592

lukejagodzinski · 2019-09-03T12:35:27Z

Is it a bug in TypeScript compiler or just libraries' code is faulty? Maybe TS team should come up with some guidance how to write code to avoid this bug if it's not an issue with tsc itself. It's really frustrating that it didn't get fixed yet

error TS2321: Excessive stack depth comparing types 'DataObject<?>' and 'DataObject<?>'. See microsoft/TypeScript#21592

sandersn · 2019-09-04T21:35:10Z

@alfaproject you have a different issue. Notice that the two types are the same in your case. This is a known bug (#33132) with a fix at #33144. We'll ship it in 3.6.3 in the next week or so.

tomaswrobel · 2021-03-21T12:48:12Z

I hate this bug. The only thing is work agains it is // @ts-ignore

this was added to our typing to work around issue described in microsoft/TypeScript#21592 - however, as of TS 3.6.3 it has not been an issue

this was added to our typing to work around the issue described in microsoft/TypeScript#21592 - however, as of TS 3.6.3 it has not been a problem

sandersn · 2021-11-05T18:22:56Z

Fixed in 3.7

mhegazy added the Bug label Feb 3, 2018

mhegazy assigned sandersn Feb 3, 2018

mhegazy added this to the TypeScript 2.7.2 milestone Feb 3, 2018

pelotom mentioned this issue Feb 12, 2018

Conditional types #21316

Merged

mhegazy modified the milestones: TypeScript 2.7.2, TypeScript 2.8 Feb 12, 2018

Conaclos mentioned this issue Mar 3, 2018

Excessive stack depth comparing types with 2.7.1 #21671

Closed

mhegazy modified the milestones: TypeScript 2.8, TypeScript 2.8.1 Mar 9, 2018

sandersn mentioned this issue Mar 15, 2018

Improved type relation for recursive mapped types #22612

Closed

daniel-lang mentioned this issue Mar 19, 2018

TypeScript 2.7.1 update cause repository.save(entity) error typeorm/typeorm#1544

Closed

sandersn added the Fixed label Mar 19, 2018

DanielRosenwasser modified the milestones: TypeScript 2.8.1, TypeScript 2.8.2 Mar 19, 2018

mhegazy modified the milestones: TypeScript 2.8.2, TypeScript 2.9 Apr 3, 2018

ghost mentioned this issue May 9, 2018

[Lodash] Excessive stack depth comparing types DefinitelyTyped/DefinitelyTyped#25632

Closed

mhegazy modified the milestones: TypeScript 2.9, TypeScript 2.9.1 May 10, 2018

mhegazy modified the milestones: TypeScript 2.9.1, TypeScript 3.0 May 17, 2018

mhegazy modified the milestones: TypeScript 3.0, TypeScript 3.1 Jul 2, 2018

sandersn modified the milestones: TypeScript 3.6.0, Backlog Jun 14, 2019

sandersn removed their assignment Jun 14, 2019

hswhite33 mentioned this issue Jun 20, 2019

TypeScript: Excessive stack depth comparing generic preloadedState with DeepPartial reduxjs/redux#3454

Closed

mophy mentioned this issue Jul 12, 2019

Excessive stack depth comparing types 'FindConditions<?>' and 'FindConditions<?>' (with solution) typeorm/typeorm#4427

Closed

mophy mentioned this issue Jul 22, 2019

fix the Excessive stack depth comparing types FindConditions<?> and… typeorm/typeorm#4470

Merged

raymondfeng added a commit to loopbackio/loopback-next that referenced this issue Aug 28, 2019

chore(repository): workaround for recursive DeepPartial

d656c54

error TS2321: Excessive stack depth comparing types 'DataObject<?>' and 'DataObject<?>'. See microsoft/TypeScript#21592

raymondfeng added a commit to loopbackio/loopback-next that referenced this issue Aug 29, 2019

chore(repository): workaround for recursive DeepPartial

7f1ea6f

error TS2321: Excessive stack depth comparing types 'DataObject<?>' and 'DataObject<?>'. See microsoft/TypeScript#21592

alfaproject mentioned this issue Sep 2, 2019

Mark deep indexed access comparisons as expanding #33144

Merged

bajtos pushed a commit to loopbackio/loopback-next that referenced this issue Sep 3, 2019

chore(repository): workaround for recursive DeepPartial

18a4bba

error TS2321: Excessive stack depth comparing types 'DataObject<?>' and 'DataObject<?>'. See microsoft/TypeScript#21592

bajtos pushed a commit to loopbackio/loopback-next that referenced this issue Sep 3, 2019

chore(repository): workaround for recursive DeepPartial

d5237cb

error TS2321: Excessive stack depth comparing types 'DataObject<?>' and 'DataObject<?>'. See microsoft/TypeScript#21592

ff6347 mentioned this issue Sep 4, 2019

upgrade deps technologiestiftung/flusshygiene-postgres-api#145

Merged

ssube mentioned this issue Sep 8, 2019

update: update dependency typescript to v3.6.3 ssube/isolex#399

Merged

1 task

Benno007 mentioned this issue Nov 4, 2019

Update DeepPartial Type typeorm/typeorm#5026

Closed

plastikfan mentioned this issue Mar 4, 2020

TS2589: Type instantiation is excessively deep and possibly infinite caused by non recursive generics when using "npm link" #37209

Closed

imnotjames mentioned this issue Jul 31, 2021

chore: remove workaround for "Excessive Stack Depth" from TS3.2 typeorm/typeorm#7996

Merged

7 tasks

sandersn closed this as completed Nov 5, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Excessive Stack Depth from DeepPartial/RecursivePartial in 2.7.x #21592

Excessive Stack Depth from DeepPartial/RecursivePartial in 2.7.x #21592

kevinbeal commented Feb 3, 2018

Conaclos commented Mar 3, 2018 •

edited

Loading

kevinbeal commented Mar 5, 2018

Conaclos commented Mar 5, 2018

sandersn commented Mar 14, 2018

chirdeeptomar commented Jun 2, 2018

rafaelbatistamarcilio commented Jun 2, 2018

hswhite33 commented Jun 20, 2019

sandersn commented Jun 20, 2019

Yaojian commented Aug 15, 2019

alfaproject commented Aug 28, 2019

lukejagodzinski commented Sep 3, 2019

sandersn commented Sep 4, 2019

tomaswrobel commented Mar 21, 2021

sandersn commented Nov 5, 2021

Excessive Stack Depth from DeepPartial/RecursivePartial in 2.7.x #21592

Excessive Stack Depth from DeepPartial/RecursivePartial in 2.7.x #21592

Comments

kevinbeal commented Feb 3, 2018

Conaclos commented Mar 3, 2018 • edited Loading

kevinbeal commented Mar 5, 2018

Conaclos commented Mar 5, 2018

sandersn commented Mar 14, 2018

chirdeeptomar commented Jun 2, 2018

rafaelbatistamarcilio commented Jun 2, 2018

hswhite33 commented Jun 20, 2019

sandersn commented Jun 20, 2019

Yaojian commented Aug 15, 2019

alfaproject commented Aug 28, 2019

lukejagodzinski commented Sep 3, 2019

sandersn commented Sep 4, 2019

tomaswrobel commented Mar 21, 2021

sandersn commented Nov 5, 2021

Conaclos commented Mar 3, 2018 •

edited

Loading