Repository navigation
TypeScript 7.1 Iteration Plan #63703
Description
Activity
- pinned this issue
on Jul 31, 2026 2027, is that a typo?
Reacted by Daniel Rosenwasser, Zhang sile, Sanbei, Vision and KushalSure is! 🫠🤦♂️
Reacted by Dasa Paddock, Mikhail Shornikov, Jeppe Reinhold, Roman, Enzo Coelho Albornoz, KoHaRxnP, Zak Nesler, MasuqaT (T.Okada), Vlad, Connor Bär and 27 more- added 2 commits that reference this issue
on Aug 24, 2026 For anyone following along - we're thinking we want a bit more time to make sure we get testing on the API, and we don't want a lot of churn following the beta. So we are looking at pushing out the beta about 2 weeks further. Details to come on what that means for the RC and final release dates too.
Reacted by Roman, João Ferreira, Valentin Semirulnik, Kirk Waiblinger, Tobbe Lundberg, lin72h, Luke Deen Taylor, Nicolas Stepien, Zak Nesler, Matt Garrett and 32 moreGlad to see all the performance improvements!
Speaking of which, does the team plan to revisit the instantiation depth limits and similar errors in the tsgo compiler? These numbers were chosen arbitrarily for the tsc performance target and the original reasoning is no longer applicable.if c.instantiationDepth == 100 || c.instantiationCount >= 5_000_000 { // ... c.error(... Type_instantiation_is_excessively_deep_and_possibly_infinite) }The ecosystem has been moving to ever increasing instantiation count in the pursuit of the e2e type safety. With StandartShema validation libraries like zod providing the foundation and typed api clients\metaframeworks extending the chain all the way to the frontend. Once generics\discriminants are thrown into the mix there are legitimate cases where old limits become a bottleneck.
We have no plans to change these limits. It would be a shame to make the compiler fast only to increase depths and go slow again.
See also: microsoft/typescript-go#1637
Reacted by Roman, Ryan Cavanaugh, João Ferreira and ken7253We have no plans to change these limits. It would be a shame to make the compiler fast only to increase depths and go slow again.
See also: microsoft/typescript-go#1637
The Jevons paradox is phenomenon when technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resourceThis has always been the trajectory of the compute innovation. We don't use improved efficiency just to run our Nokia's for a year on a single charge, we run liquid glass instead.
The old limits don't make deep instantiation run faster, they just prevent it from running at all! Considering that the rise of limits doesn't even impact projects that don't cross them, i don't see the reason why it can't be at least a compiler flag.
This policy reads extremely backwards to the spirit of progress and innovation. Let users decide if they want speed or capability.
Reacted by Nicolas Stepien, Ítalo Masserano, João Ferreira and NikLet users decide if they want speed or capability.
Users don't decide how their dependencies' declaration files are written. It's a very bad experience if you install
supercool-liband it wildly misbehaves in unpredictable ways because it depends on extremely deep instantiation, which you then have to turn on everywhere and slow down all your other inference.Reacted by Roman, Kirk Waiblinger, João Ferreira, Daniel Rosenwasser, Oleksandr Tarasiuk and Madeline GurriaránI should also add - one of the goals of content mappers is that you can move a lot of this hypercomplex meta-programming type inference stuff into a static process that produces a much, much faster static .d.ts file. The projects writing SQL/GraphQL/etc parsers in the type system should be looking into this.
Reacted by Kirk Waiblinger, Roman, João Ferreira, Daniel Rosenwasser, Oleksandr Tarasiuk and Christian SvenssonReacted by Christian Svenssongreat work thank you!! are you also planning to fix all memory leaks? latest version gets to 30-40+ GB RAM quite often (from vscode)
Please file an issue if you have something that reproduces.
Reacted by Alexander Kachkaev, Daniel Rosenwasser and SanbeiThere have been several off topic messages in a row. I'm subscribed to this issue to track when 7.1 comes into beta testing. If you're not commenting on progress towards 7.1, please find a relevant issue to comment on or file a new issue. Thanks.
Reacted by Serge Nalishiwa, Daniel Rosenwasser, Egor Blinov, Metin Bektas, Roman, João Ferreira, Matthias Günter, Holger Jeromin, Jan, Alexander Kachkaev and 21 moreReacted by Jan, maxwell-at-zellerfeld, Boris, Graham Preston, Seanitzel(Sean Ray Dvir), kh4f, Vinicius Lourenço, Momin Khan, Andrew Aaron Qi, Maciej Bukczynski and 1 more- added a commit that references this issue
on Sep 9, 2026 Due to a lot of infrastructure issues, we'll be at least a few days late on beta.
Reacted by Luke Ramus, pravin-adhav-qp, João Dias, Vishal Kumar, Akam Foad, João Ferreira, Sacha Stafyniak, Boris, Yusuke Yamada, Mira Šerý and 20 moreReacted by n028, Seanitzel(Sean Ray Dvir), liam, Max, Stav Alfi, João Ferreira, maik-bol, rbnts, maxarvid, Alexander Kachkaev and 13 moreReacted by Alexander Simbirtsev, Matheus Cardoso, Colin McDonnell and Uwe S.
Language and Compiler
typeOn Import Attributeses2026option forlibandtargetlib.d.tsUpdates for New Iterator MethodsPromise.allKeyedandPromise.allSettledKeyedlib.d.tsUpdates for DOMEditor Productivity
Performance
switch/caseNarrowing on UnionsInfrastructure
Website