Repository navigation
TypeScript 5.5 Iteration Plan #57475
Description
Activity
- pinned this issue
on Feb 22, 2024 How much of an impact will
--isolatedDeclarationshave on type checking performance in large projects?None directly, in the same way that
isolatedModulesdoesn't speed things up in and of itself.But, if you have code which passes
isolatedModules, it can be safely transpiled by an external tool (like Babel, esbuild, swc). And similarly, code passingisolatedDeclarationscan be transpiled into a declaration file by an external tool too (once one exists).Reacted by Kirill Groshkov and Bnaya Peretz(This isn't to say that there can't be some speedups possible in TypeScript in the future enabled by this option, just that the flag itself is intended to just be checks.)
Reacted by Kevin BarabashHey everyone, any chance of getting #26242 in this release? It was proposed back in 2018 and there has not been much work on the issue up to this point. Getting it at least planned would already be amazing to the TS community. I believe it would substantially improve the power of TS in the long run!
Reacted by Yamiteru, green-mike, 김회준, Gaute Løken, whzx5byb, Gabriel Rocha de Oliveira, Srigi, Bo Lingen, Sirapop Iam-o-pas, Marcos G. Souza and 28 moreReacted by Bo Lingen, Zachary Rabe and Justin LeiderReacted by Bo Lingen, Jonathan MASSUCHETTI, Joshua Pendragon, bigmistqke, Zachary Rabe, Justin Leider and Jon Ege RonnenbergJust a heads up, I'm working on remaking the website using Sveltekit. Styles will be the same, but the overall structure will be simpler and much quicker to iterate on.
@ClearedFram3 while I don't want to discourage experimentation, I don't think we would accept such a large PR without discussing changes ahead of time.
Reacted by AlexDaniel Rosenwasser (@DanielRosenwasser) I should've said the codebase structure will be different—the website style/content structure will be the same. After the current codebase is replaced, there will ample room for discussion about changing design and content or even to a different framework haha.
I’ve been watching the iteration plan threads from 5.4 seeing my PR (#55600) on the list. I am on standby anytime for any necessary alternations.
Reacted by Daniel Rosenwasser and Kirill GroshkovIs there anything Typescript community members can do to influence this list?
I think I can speak for every TS React dev on the planet when I say that #29526 (improved syntax for destructuring an argument ... like the React
propsargument) has languished long enough. The community has essentially reached a consensus on a desired syntax in that ticket (something that was not easy), and now all that's needed is developer will to implement.I can't speak for anyone else, but personally I would trade everything on the 5.5 list for this one feature!
Reacted by Bo Lingen, Christian Meredith, Jonathan MASSUCHETTI, Eric Haynes, Anton Bessonov, bgenia, PartMan, Juhan Oskar Hennoste and Vladyslav HubaReacted by nyngwang, mdh and Paweł DymaraReacted by _typedev, Risto Keravuori, Vitali Kuzmich, David Sundqvist, Dmitrii Pikulin, Even Torset, Krisztian Horvath, Alisson Cavalcante Agiani, Bo Lingen, ceneau and 9 moreA question about Investigate Recursive Object Type References
Will it help i.e. in zustand in avoiding writing interface for the state, and instead just infer the type from the initial state (create-function argument)?Is there any chance after 10 years.. to introduce nameof?
Is it super complicated? Honest question
Reacted by Anton Bessonov and bgeniaReacted by Joe Calzaretta, Nicolas Stepien, Tyler Church, Paweł Dymara and Vladyslav Huba43 remaining items
These iteration plans are only a prospective list; in this case I had other critical work that preempted me working on anything tangible for LSP.
What use case do you have where LSP would be valuable?
Jake Bailey (@jakebailey) We met with Daniel a few months ago to discuss our project. It's a TypeScript-based DSL with a custom file extension for which we need to implement our own VS Code extension. Our DSL is a subset of TypeScript so we need to disallow certain things and provide custom completions, etc. We implemented some of this as a
tsserverplugin, but we don't want our customers to havetsconfig.jsonfiles in their projects. We don't intend to provide any of the same configuration options you get with atsconfig.json. We have our own config file. We want them to simply install the VS Code extension and for everything to work.It is possible to load a
tsserverplugin inside a VS Code extension without requiring the user to have atsconfig.json, but since there is only one instance oftsserverrunning at a time in VS Code, this plugin would then be active for all of the user's TypeScript files unless they disable the extension.Our options are thus: (A) Fork the internal
typescript-language-featuresextension, (B) implement an extension from scratch using a community-developed LSP wrapper like vtsls, or (C) implement an extension from scratch usingtsserverdirectly with our own LSP adapter layer.I don't really see how LSP would help that situation; LSP will within reason only change the way tsserver talks to the editor. It'd still be the same
ProjectServiceunder the hood, with the same gotchas. What you're describing sounds more suited to plugging into something likevolar, the system that vue, mdx, etc, use to slap their custom languages on top of TS. (Not that I have any experience with it, or that it's supported by TS in any way.)In any case, I think this is the wrong place to discuss it (pinging everyone interested in the 5.5 release process); the update is just that "I didn't have time to work on it". The current LSP thinking is to slowly onboard calls away from the old protocol onto the new one, so it's not going to be like one day we aren't LSP and one day we are, either.
Reacted by Ryan Palmer, ExE Boss and Caleb JasikTypeScript Bot (@typescript-bot) bump release-5.5 and LKG
Reacted by TypeScript BotHey, Daniel Rosenwasser (@DanielRosenwasser)! I've set the version of release-5.5 to 5.5.3 for you.
5.5.3 is out with the NuGet/VS issues fixed. Thanks for your patience everyone!
Reacted by Guillaume Humbert, Holger Jeromin and Toni VillenaWill #26242 be implemented in the next version, as it is so important to library developers?
Reacted by FenyingTypeScript Bot (@typescript-bot) bump release-5.5 and LKG
Reacted by TypeScript BotHey, Daniel Rosenwasser (@DanielRosenwasser)! I've set the version of release-5.5 to 5.5.4 for you.
- added a commit that references this issue
on Jul 25, 2024 - unpinned this issue
on Sep 9, 2024 Is there any reference link for
Improved Performance for Git Branch Switching Scenarios? Daniel Rosenwasser (@DanielRosenwasser) Thank you!Reacted by Toni Villena
This document outlines our focused tasks for TypeScript 5.5. It minimally indicates intent to investigate tasks or contribute to an implementation. Nothing is set in stone, but we will strive to complete these tasks in a reasonable timeframe.
gantt dateFormat YYYY-MM-DD TypeScript 5.4 Stabilization Period : 2024-02-16, 2024-03-05 TypeScript 5.5 Beta Development : 2024-02-16, 2024-04-19 TypeScript 5.5 RC Development : 2024-04-20, 2024-05-31 TypeScript 5.5 Stabilization Period : 2024-06-01, 2024-06-18 todayMarker stroke-width:5px,stroke:#0f0,opacity:0.5Compiler and Language
--isolatedDeclarationsFlagtsconfig.jsonFilesdefaultImport Interop ConfigurabilitydefaultImport Detection from ECMAScript ModulesSetMethodslib.d.tsUpdatesEditor and Language Service
Performance
--incrementalModeWebsite and Docs
Infrastructure
--isolatedDeclarationsand Parallelize TypeScript's Build