Repository navigation
Document TypeScript version lifetime and EOL #49088
Description
Activity
With another release of TypeScript coming around the corner, I'm curious if there's been some official thought on this?
To my knowledge, we don't have an official policy beyond the one implied by the fact that we ship our components in Visual Studio. Security fixes are backported I believe for the last year of releases; non-security fixes are not backported. If there's a more concrete definition of "support" provided, or a specific hypothetical you had in mind, I can speak to that specifically.
Reacted by Martin DevillersThere is also this paragraph in the documentation on https://github.com/microsoft/TypeScript/wiki/TypeScript%27s-Release-Process#what-gets-done-for-patch-releases :
Patch releases are periodically pushed out for any of the following: ... These fixes are typically weighed against the cost (how hard it would be for the team to retroactively apply/release a change), the risk (how much code is changed, how understandable is the fix), as well as how feasible it would be to wait for the next version.
If the concept of
version lifetimeandEOLis irrelevant with TypeScript, then we can close this issue.If that's the case, then are bugfixes going to be backported and language features backported to older versions of the typescript compiler?
That is the expectation of a "supported" version of such a piece of software.
Reacted by Mark SmithJumping in as I've been bit by the unclear lifecycle for TypeScript before: this is inconsistent with other Microsoft languages and software distributions. .net (core and otherwise) has a very clear lifecycle document which sets expectations well for users.
From a quick look through the release history, it doesn't appear to me that there are many updates made to prior major versions once a new major version (or even generally minor version) has hit stable; I had to search all the way back to June 2021, where 3.9, 4.0, and 4.1 got patches for Node 16, when 4.3 was the current stable version.
That dotnet policy document states, "Every Microsoft product has a lifecycle. The lifecycle begins when a product is released and ends when it's no longer supported." Does typescript abide by the Modern Policy Lifecycle? If not, why not?
Reacted by Luis Schaab, Martin Devillers, Morgan Gangwere, nicow-odit, Peter Klooster and Jesse SilversteinAny progress on this?
Reacted by Martin JohnsWe've now published a clarification of support at https://github.com/microsoft/TypeScript/blob/main/SUPPORT.md, and have closed this issue.
Reacted by AmirR H., Nhat Pham, satoruhanazawa-cct, David Ferreira, Francisco Susana and Matej CotmanCan we reopen this, please?
I'm one of the maintainers of the
uuidmodule. Our platform support policy fornodehas been "uuidsupports all current node LTS versions, plus one prior release". This works well for us because it lets us plan how / when code and platforms can be deprecated.
Having recently added TS support, it's quickly become apparent that we should have a similar policy for TypeScript.While trying to answer the question, "What is the Typescript release and support lifecycle?", I've landed here.
The
SUPPORT.mdpage that Paul Chapman (@PoulChapman) links to is disappointingly unhelpful. It provides a link to MSFT's generic Modern Support Policy, where searching for "typescript" returns zero results, and little else.Regarding Ryan Cavanaugh (@RyanCavanaugh)'s comment about TS being implicitely tied to VS's release lifecycle, that's maybe a bit more helpful, but I see no mention of TS version on the VS 2022 release page. I suppose I could go google-golfing a bit further to see what versions of TS ship with each of those releases, but that's more work than I'm willing to put into this question.
It'd be great if there were a graphic for TS like this one that showed up at the top of my Google results when seeking an answer... except, you know, from an official source with some credibility. See also the previously mentioned Node.js Releases page for other inspiration.
Reacted by Matej Cotman"Support" is a hard term to define; do you mean fixes to behavior? Crash fixes? Security fixes? Stability guarantees?
We release quarterly. Only the previous version is supported for bugfixes only (mainly bad regressions, crashes). We may patch older versions for security fixes (very very rare, there really isn't much that can be CVE'd such that that's required).
If you use this pattern to determine your support window, you'd only be supporting one TS version. That doesn't seem right; all we're saying is that we aren't going to go futz with the behavior of old TS releases, which would imply more stability if anything.
Definitely Typed maintains compatibility with the last two years of TS releases (https://github.com/DefinitelyTyped/DefinitelyTyped#support-window). This is also the general window
typescript-eslintuses. I think that for a library maintainer, that window is a much more reasonable guideline to use than TypeScript's own support policy for the compiler itself.Many projects determine that to be too large of a range too and support less.
You can also use projects like
tstycheto test your code against multiple versions of TS, or some other alternative.Jake Bailey (@jakebailey) Thanks for this update. The "two years" cutoff concept is helpful. It sounds like we should just take a similar stance then.
Reacted by Robert Kieffer- added a commit that references this issue
on Aug 22, 2026
Bug Report: Documentation.
There is no documented lifecycle time for a particular version of TypeScript.
Python, Go, and Node all have defined lifetimes for releases.
🔎 Search Terms
🙁 Actual behavior
No documentation exists.
🙂 Expected behavior
Having a list or guideline of how long versions of the TypeScript library/compiler/etc are supported for so that I can make informed decisions on security and SDLC inquiries.