dfee
Type instantiation is excessively deep and possibly infinite.ts (2589)
Hi,
When using NavBar, I got an error in VSCode:
Type instantiation is excessively deep and possibly infinite.ts(2589)
Apparently it's linked to https://github.com/microsoft/TypeScript/issues/30188 where they recommend to use ts-toolbelt for complex types.
Ran into this issue as well. Downgrading typescript to 3.5 actually did work but I'm curious if anyone else seeing this issue on [email protected]?
Downgrading typescript solves the issue and builds successfully but the latest VSCode shows the same error Type instantiation is excessively deep and possibly infinite.ts.
@shakib609 That's because VSCode uses its own bundled Typescript version by default.
Open your workspace and a .ts file in it. On the bottom ribbon, next to TypeScript or TypeScript React is displayed the current TypeScript version. Click on it and select Use workspace version.
Assuming you already installed TypeScript 3.5.x : yarn add [email protected]
I have same issue on <Container /> component.
Any idea instead of downgrading the TS version?
Hi @dotamir
Did you test it with typescript 3.6.4 ?
Base on https://github.com/microsoft/TypeScript/issues/33132 it should have been resolved.
@arnaud-deprez yes, My project is using typescrit 3.6.4 version but still had this issue.
It is kind of a hack but I'm currently using this patch as a workaround for this problem: https://github.com/zookatron/rbx/commit/8880054bbf9819473b1732a6751aa19eabb6aae5
I haven't had time to dig into this too deeply yet but there appears to be some utility types such as Prefer which are frequently used and are creating very deeply nested types which slows down type checking significantly and causes this "Type instantiation is excessively deep" error on recent TypeScript versions. These would need to be refactored into something simpler (though probably less expressive) in order to fully address this problem.
Hotfix above fixed some cases with containers but getting it on some Navbar.Item elements too now, running [email protected]. Downgrading typescript to 3.5.2 resolved the issue. Would be nice to see this fixed with new versions of typescript.
hey team, any news on this one? I've had to downgrade to 3.4 to avoid some other issues with 3.5, which isn't ideal.
It would seem that this might not be an issue with typescript, more that they have tightened up the limits on this. Most issues that I saw on the TS repo on this issue seems be with the code, not with TS itself.
Are there any maintainers looking into this? Is there any ongoing work sorting out the types, maybe introducing ts-toolbelt, or would help be accepted?
I am just investigating into this myself. It appears the Prefer type doesn't do much. I think the purpose is to allow the types of the variables to be overridden, e.g. change a string into a number, but I can't see any instances of that happening. It's possible it's a leftover from an old pattern.
Can anyone point to a place in the code where it's using the Prefer type with something other than an empty interface as the preferred type? Perhaps we could use a conditional type here to bypass the Omit<>, which I assume is the expensive part, when the override type is empty.
Maybe use this instead:
export type Prefer<P, T> = {} extends P ? T : P & Omit<T, keyof P>;
I need to get my machine setup to run this project tonight, but VSCode appears to be happy with it
Edit: Fork here https://github.com/luhis/rbx Tests are passing against TypeScript 3.8.3 2nd Edit: Actually no, it's not working, but I think i'm on the correct path.
@luhis There does appear to be a lot of places where Prefer is used with an empty interface due to overrides interfaces that are never actually overridden, so a type conditional might help with that.
The big one though is in src/base/exotic.ts where Prefer used with the generic TOwnProps type parameter where it will pick up the prop types of the passed component. The author created a useful blog post here with some explanations as to what is going on there.
TypeScript 3.9 has been released, there are some changes of note here: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-9.html#speed-improvements
Our team has been focusing on performance after observing extremely poor editing/compilation speed with packages like material-ui and styled-components
In my branch had all tests passing in TypeScript 3.8, but one error build error in the Breadcrumbs. That disappeared as soon as I moved to TS 3.9.
There were a few changes I made to update RBX to TS 3.9, but in theory the error should be gone if you update your project consuming RBX to TS 3.9
It is indeed better & functional with Typescript 3.9. However, with the RBX type definitions in play, my editing experience (VSCode/Intellisense) goes from zippy fast to frustratingly slow. YMMV, of course.
I fixed this issue by updating to TypeScript 3.9.5 and then running "TypeScript: Select TypeScript version" inside VSCode to change it and then restart the editor :)
For what it's worth this issue seems to have come back in TypeScript v4.x! So stay on 3.9.x!
Nevermind! The Table component chokes on 3.9.5 and 4.x 🙁
For what it's worth this issue seems to have come back in TypeScript v4.x! So stay on 3.9.x!
Nevermind! The
Tablecomponent chokes on 3.9.5 and 4.x 🙁
I know this is a late reply...but work around I've found is to use <tbody> instead of <Table.Body>
there is another option to work around this, use Preact instead of React, for some reason it works much better, the Preact type definitions are simpler or something i suppose