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

Recursive types error: Type instantiation is excessively deep #45672

Open
vlazh opened this issue Sep 1, 2021 · 12 comments
Open

Recursive types error: Type instantiation is excessively deep #45672

vlazh opened this issue Sep 1, 2021 · 12 comments
Assignees
Labels
Needs Investigation This issue needs a team member to investigate its status. Rescheduled This issue was previously scheduled to an earlier milestone

Comments

@vlazh
Copy link

vlazh commented Sep 1, 2021

Bug Report

I had got error Type instantiation is excessively deep and possibly infinite. in my JSON types - value to JSON transformation.
It's some new limitation introduced from v4.3.2?
Works fine with v4.2.4.

🕗 Version & Regression Information

  • This changed between versions 4.2.4 and 4.3.2

⏯ Playground Link

I couldn't get to make a short and simple example because when I removing any recursive type reference then error will disappeared.

Playground link with relevant code

@andrewbranch
Copy link
Member

Re-opened from #44281, possibly related: #45632, #45576

@andrewbranch andrewbranch added the Bug A bug in TypeScript label Sep 1, 2021
@andrewbranch andrewbranch added this to the TypeScript 4.5.0 milestone Sep 1, 2021
@andrewbranch andrewbranch added Needs Investigation This issue needs a team member to investigate its status. and removed Bug A bug in TypeScript labels Sep 1, 2021
@andrewbranch
Copy link
Member

@weswigham didn't we start doing more to relate conditional types around that time frame? I seem to recall some increase in these kinds of errors was expected. But this example takes a super long time to even finish checking, and it’s nearly instant in 4.2.

@weswigham
Copy link
Member

We did definitely add rules for relating conditional type constraints around then, I think.

@andrewbranch
Copy link
Member

#37208?

@andrewbranch
Copy link
Member

Indeed, reverting that “fixes” this issue.

@andrewbranch andrewbranch added this to Agenda in Design Meeting Docket via automation Sep 3, 2021
@jakearchibald
Copy link

jakearchibald commented Sep 7, 2021

I think this issue is impacting a couple of my libraries, as the IDBValidKey type references itself.

Here's the pattern that's causing a problem. It isn't a problem in 4.3.5.

@andrewbranch
Copy link
Member

Spoke with @weswigham about this and he mentioned we might be able to apply a targeted fix by swapping the order of checks for conditional types.

@vlazh
Copy link
Author

vlazh commented Mar 21, 2022

It looks like the issue was fixed by the version 4.6.2. Isn't it?

@jakearchibald
Copy link

This example still fails in 4.6.2. Not sure if that's intended.

@vlazh
Copy link
Author

vlazh commented Mar 21, 2022

This example still fails in 4.6.2. Not sure if that's intended.

I found two deep recursions: IDBValidKey and IsExact -> DeepMakeRequiredForIsExact.
If splits IDBValidKey into two types the error goes away. But they not the same. Not allowed IDBValidKey[][][]... Example.

@jakearchibald
Copy link

But this seemed to work fine in 4.3.5

@hasgar-aot
Copy link

any fix? it's kind of annoying
v4.0.3
fails in 4.3.5 too.

@RyanCavanaugh RyanCavanaugh added the Rescheduled This issue was previously scheduled to an earlier milestone label May 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Investigation This issue needs a team member to investigate its status. Rescheduled This issue was previously scheduled to an earlier milestone
Projects
None yet
Development

No branches or pull requests

6 participants