TypeScript
TypeScript copied to clipboard
microsoft
TypeScript 5.0 Iteration Plan
This document outlines our focused tasks for TypeScript 5.0. 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.
| Date | Event |
|---|---|
| November 15th | TypeScript 4.9 Release |
| January 20th | Create 5.0 Beta (5.0.1) Build for Testing |
| January 24th | TypeScript 5.0 Beta Release |
| February 24th | Create 5.0 RC (5.0.2) Build for Testing |
| February 28th | TypeScript 5.0 RC Release |
| March 10th | Create 5.0 Final (5.0.3) Build for Testing |
| March 14th | TypeScript 5.0 Final Release 🚀 |
gantt
dateFormat YYYY-MM-DD
TypeScript 4.9 Stabilization Period : 2022-10-28, 2022-11-11
TypeScript 5.0 Beta Development : 2022-10-28, 2023-01-19
TypeScript 5.0 RC Development : 2023-01-19, 2023-02-23
TypeScript 5.0 Stabilization Period : 2023-02-23, 2023-03-14
todayMarker stroke-width:5px,stroke:#0f0,opacity:0.5
Language and Compiler Features
- ECMAScript Decorators
- Unify All
enums as Unions - Legacy Flag Deprecation
- Investigate Bundler-Oriented Module Resolution Options
- Support
.tsas a Module Specifier for Bundler/Loader Scenarios - Declaration Files for Non-JavaScript Files
- Allow Arrays in
extendsfortsconfig.jsonFiles - Investigate Per-File Settings
lib.d.tsUpdates- Make
@types/webVersionable
Editor Productivity
switch/caseSnippet Completions- Investigate
SharedArrayBuffer-Backed Host for Web Editing Contexts - Investigate Limited ATA-Like Scenarios in Web Editing Contexts
- Implement Cancellation in Web Editing Contexts
- Easy Run/Debug for Loose TypeScript Files
Performance
- Investigate Module Resolution Caching in
.tsbuildinfoFiles - Optimizing
.tsbuildinfo - Investigate Tooling for JIT Deoptimizations
Infrastructure
Website
The 4.9 iteration plan is over at https://github.com/microsoft/TypeScript/issues/50457.
It's so sad that adding proper type support for throw is not on the roadmap for v5...
One idea I had previously floated to @amcasey was to add compiler/server APIs with asynchronous signatures in 5.0 (even if they're still synchronous under the hood), and deprecate the synchronous APIs. This would allow Typescript to later (6.0?) remove the synchronous APIs and unblock the ability to perform asynchronous I/O (or even worker-based parallelization?) in future versions.
I’d love to see the core team engage with issues that are for example 400+ thumbs up and marked “awaiting feedback” rather than issues that seem less important. Even if the answer is that the team consider it to not be typescript’s responsibility and close the issue - i would rather that than limbo and newer but less important features being tackled.
https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3A%22Awaiting+More+Feedback%22
I’d love to see the core team engage with issues that are for example 400+ thumbs up and marked “awaiting feedback” rather than issues that seem less important. Even if the answer is that the team consider it to not be typescript’s responsibility and close the issue - i would rather that than limbo and newer but less important features being tackled.
https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3A%22Awaiting+More+Feedback%22
Waiting for any news on LSP implementation
Any plan to add experimental support ECMAScript Operator Overloading, Pipeline Operator or extension methods?
@mindlid It would be highly inappropriate to add support for any proposal prior to stage 3.
@ljharb any feature can be added despite being a proposal or not, that's the point of being a superset of javascript
@mindlid can be, sure. but a) it's not a superset in any way, and b) proposals aren't in JavaScript until they're stage 4, so your argument doesn't hold up anyways.
a) it's not a superset in any way
hmm... aren't features like string literate templates or enums not superset features???? Any feature in TS which is not in JS falls into the SuperSet, including the type system, it's basic set logic.
b) proposals aren't in JavaScript until they're stage 4
okay, don't be confused, who is talking about JS?, Typescript is not limited to the features of Javascript, JS it's only a subset of the TS superset. According to your logic, you may want to remove the type system from Typescript until Proposal Type Annotations gets into Javascript
It would be highly inappropriate to add support for any proposal prior to stage 3.
Features like Decorators have been in experimental support before Stage 3, that why you run them with --experimental<featureName>, and that's why the --experimental<featureName> parameters exist
TS is not just JS with types, is it's own set of unique features plus the ones of JS
@ljharb
@mindlid yes, and TS's inclusion-by-default of a five-times-obsolete form of decorators is one of the larger mistakes it's made, as I believe they've acknowledged. I'm well aware TS is not just JS with types - that's why it's not a superset.
The issue is that pre-stage-3 features are subject to change a lot, especially the ones you mentioned - the possible churn isn't worth it.
you cannot call a mistake to change a experimental feature, that's the point of being marked as experimental, users can test, give feedback, improve the design, typescript is used as guinea pig for some future ECMAScript features, so thanks Typescript for your "failures", so the final ECMAScript feature will learn from your errors.
On the other hand if you use an experimental feature treating it as stable, and complaining about breaking changes, that's not a Typescript mistake, but a clear misunderstanding of the purpose.
@ljharb
@mindlid I'm going to stop arguing about this here since the TS team has stated their policy on this in the past, and it's not worth discussing unless they change it :-) TC39 has lots of ways to get feedback on syntax features prior to stage 3, and "ship them in TS" needn't be one of them.
TS team, I urge you to hide these comments since they will likely be distracting to those attempting to read the issue.
Dear TS team, i really appreciate and respect your excellent work, but so much people are waiting for the throws statement, why isn't it in the 5.0 roadmap? FMPOV this functionality is directly related to the purpose of the existence of the TypeScript – typed JS. This is the feature i really miss more then any other feature – it lacks type-safety a lot.
Would be very grateful if some of team members could give a reply about it
I think we'll probably take a post-5.0 activity of "Saying 'no' to a bunch of things that aren't going to happen in the next five years" (I can't wait for the flood of 👎s that's going to get me 😀).
I would request that people not use the 5.0 iteration plan any further for pointing out that our suggestion backlog exists.
Allowing .ts extension would enable code sharing with a Deno backend. +1 for "Support .ts as a Module Specifier for Bundler/Loader Scenarios".
"Saying 'no' to a bunch of things that aren't going to happen in the next five years"
👍 for audacity to think TypeScript will survive 5 years with such neglect to community opinion and codebase quality. That's the spirit.
Ah so it's a graph of commit count. Two people who would commit on basically every keystroke (they were good engineers, it was just their style) were active over 2015-2016 and 2017-2019, and we switched to squashing commits on merge around 2020 IIRC. Commit count is usually not the best measure of a project's, well, anything, since it entirely depends on arbitrary things like squashing and how often the people working on the project like to do intermediary commits. Of all the things that worry me about TS's future, not having enough git objects is the least of my concerns 😅
Of all the things that worry me about TS's future
Could you please share your thoughts about these things? Would be very interesting to read!
Great to see TypeScript evolve even further, thanks for the time invested in this project!
With that being said, I am a little bit surprised as this hardly seems like a major release. Most of these changes are relatively niche and hardly breaking changes.
I understand this is not an issue to post suggestions so I won't. I just want to express that this release seems disconnected from the current TypeScript "issues". For example, having an option is tsconfig.json to force all thrown to be instances of Error and thus make error not be unknown but Error in try..catch statements seems like a much more important change than unifying Enums or catering to bundlers. Actually I am surprised than catering to bundlers is within the scope of TypeScript. It seems like something that should be it's own separate thing.
Anyway, I hope we get to see more impactful changes in 5.x versions!
With that being said, I am a little bit surprised as this hardly seems like a major release. Most of these changes are relatively niche and hardly breaking changes.
I think typescript doesn't use semver because marketing or smth, meaning that for example 5.0 and 4.9 aren't that different, the versioning is just a way to know if you're on a newer or older version.
I think typescript doesn't use semver because marketing or smth, meaning that for example 5.0 and 4.9 aren't that different, the versioning is just a way to know if you're on a newer or older version.
Can anyone confirm or infirm this please? I'd be interested to know if TypeScript is following a specific logic regarding releases if not using SemVer. Versioning cannot be marketing, especially for a technology aimed exclusively at IT professionals. We need version numbers to be reliable and have a clear contract on how they behave.
Can anyone confirm or infirm this please?
https://github.com/microsoft/TypeScript/issues/51392#issuecomment-1301968974 :
Since "minor release" is often mentioned here, I'd like to add something. TypeScript does not follow semantic versioning. The version increment is always the same: Minor until 9, then major. There's no deeper meaning behind it, like "no breaking change".
Every TypeScript release should be treated as a major release, because that's what it is.
I could not find this in documentation. Maybe I did poor job searching. It would be good to have this in some central place so it would not greate more confusion. Though discussion of version practices should maybe be it's own issue (if one does not yet exists) instead in this iteration plan.
Also though all "minor" versions are "major" versions, I have seen that the team uses major for doing bigger breaking changes because that is what users expect but it's not guaranteed.
Since the version numbers and the release dates are fixed, releases will include tasks that are ready to be shipped and things that can be done for one release are limited by time.
@rubiesonthesky thanks for the link! This is going off-topic so I won't keep on going with this discussion but I appreciate the effort you put into your researches! 👍 (I also want to point out that not using SemVer and relying on x.0 => x.9 then x+1.0 => x+1.9 is absolutely terrible in my opinion)
Every new TypeScript version has breaking changes are listed at the end of its release notes. They also tend to affect a very small number of users and/or be correcting behavior that is obviously wrong. When they do require updates, they tend to limited in scope.
For a project like this, SemVer doesn't really add much value.
@RyanCavanaugh Hey, Do you have any plan to improve OOP in typescript 5.0
The roadmap page is a bit outdated
- link list to roadmap issues ends at Jun 2021
- 4.9 features are not completed
- planned 5.0 features are missing
