{"id":5203,"date":"2026-06-18T06:31:17","date_gmt":"2026-06-18T14:31:17","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/typescript\/?p=5203"},"modified":"2026-06-18T06:31:17","modified_gmt":"2026-06-18T14:31:17","slug":"announcing-typescript-7-0-rc","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-7-0-rc\/","title":{"rendered":"Announcing TypeScript 7.0 RC"},"content":{"rendered":"

Today we are excited to announce the Release Candidate of TypeScript 7.0!<\/p>\n

If you haven’t been following TypeScript 7.0’s development, this release is significant in that it is built on a completely new foundation.\nOver the past year, we have been porting the existing TypeScript codebase from TypeScript (as a bootstrapped codebase that compiles to JavaScript) over to Go.\nWith a combination of native code speed and shared memory parallelism, TypeScript 7.0 is often about 10 times faster<\/strong> than TypeScript 6.0.<\/p>\n

To get the new compiler, you can just install it from the typescript<\/code> package on npm, just like with any other release:<\/p>\n

npm install -D typescript@rc\r\n<\/code><\/pre>\n
The new Go codebase was methodically ported from our existing implementation rather than rewritten from scratch, and its type-checking logic is structurally identical to TypeScript 6.0.\nThis architectural parity ensures the compiler continues to enforce the exact same semantics you already rely on.\nTypeScript 7.0 has been evaluated against the enormous test suite we’ve built up over the span of a decade, and is already in use in multiple multi-million line-of-code codebases both inside and outside Microsoft.\nIt is highly stable, highly compatible, and ready to be put to the test in your daily workflows and CI pipelines today<\/em>.<\/p>\n
For over a year we’ve been working with many internal Microsoft teams, along with teams at companies like Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Slack, Vanta, Vercel, VoidZero, and more to try out pre-release builds of TypeScript 7.0 on their codebases.\nThe feedback has been overwhelmingly positive, with many teams reporting similar speedups, shaving off a majority of their build times, and enjoying a much more lightweight and fluid editing experience.\nIn turn, we feel confident that the release candidate is in great shape, and we can’t wait for you to try it out.<\/p>\n
Using TypeScript 7.0 RC<\/h2>\n
As mentioned above, to get TypeScript 7.0 RC, you can install it via npm:<\/p>\n
npm install -D typescript@rc\r\n<\/code><\/pre>\n
From there, you can run tsc<\/code> just like with any prior version of TypeScript, and you should see the same results as before – just much faster!<\/p>\n
> npx tsc --version\r\nVersion 7.0.1-rc\r\n<\/code><\/pre>\n
To try out the editing experience, you can install the TypeScript Native Preview extension for VS Code<\/a>.\nThe editor support is rock-solid, and has been widely used by many teams for months now.\nIt’s an easy low-friction way to try TypeScript 7.0 out on your codebase immediately.\nIt uses the same foundation as the command line experience, so you get the same performance improvements in your editor as you do on the command line.\nNotably, it’s also built on the Language Server Protocol (LSP), making it easy to run in most modern editors or even tools like Copilot CLI.<\/p>\n
Running Side-by-Side with TypeScript 6.0<\/h2>\n
Even though 7.0 RC is close to production-ready, we won’t have a stable programmatic API available until at least several months from now with TypeScript 7.1.\nGiven this, we have made it a priority to ensure TypeScript can be run side-by-side with TypeScript 6.0 for the foreseeable future without any conflicts around “which tsc<\/code> is which?”<\/p>\n
As part of the 6.0\/7.0 transition process, we’ve published a new compatibility package, @typescript\/typescript6<\/code>.\nThis package provides an executable named tsc6<\/code>, so that if needed, you can install TypeScript 7.0 (which ships its own tsc<\/code> binary) side-by-side without naming conflicts.\nThe new package also re-exports the TypeScript 6.0 API, so that you can use tsc<\/code> for TypeScript 7, while other tooling can continue to rely on 6.0.<\/p>\n
Because some tools like typescript-eslint expect to import from typescript<\/code> directly via peer dependencies, we recommend achieving this via npm aliases.\nYou should be able to run the following command<\/p>\n
npm install -D typescript@npm:@typescript\/typescript6\r\n<\/code><\/pre>\n
or modify your package.json<\/code> as follows:<\/p>\n
{\r\n  \"devDependencies\": {\r\n    \"typescript\": \"npm:@typescript\/typescript6@^6.0.0\",\r\n  }\r\n}\r\n<\/code><\/pre>\n
Note that doing this will leave you only with a tsc6<\/code> executable.\nTo get 7.0’s tsc<\/code>, you can add another alias for TypeScript 7 and npx tsc<\/code> will just work with 7.0:<\/p>\n
{\r\n  \"devDependencies\": {\r\n    \"typescript\": \"npm:@typescript\/typescript6@^6.0.0\",\r\n    \"typescript-7\": \"npm:typescript@rc\",\r\n  }\r\n}\r\n<\/code><\/pre>\n
Nightly Releases<\/h3>\n
TypeScript 7 nightlies are currently still being published under the @typescript\/native-preview<\/code> package on npm, and can be installed via<\/p>\n
npm install -D @typescript\/native-preview\r\n<\/code><\/pre>\n
The binary provided by that package is still named tsgo<\/code>.\nOnce TypeScript 7 is published with the latest<\/code> tag on npm, we expect all stable releases, major pre-releases, and nightlies to be published under the typescript<\/code> package on npm.<\/p>\n
Parallelization and Controls<\/h2>\n
TypeScript 7.0 now performs many steps in parallel, including parsing, type-checking, and emitting.\nSome of these steps, like parsing and emitting can mostly be done independently across files.\nAs such, parallelization automatically scales well with larger codebases with relatively little overhead.\nBut not every step in a TypeScript build is easily parallelizable.<\/p>\n
Checker Parallelization<\/h3>\n
Other steps, like type-checking, have more complex dependencies across files.\nMost files end up relying on the same type information from their dependencies and the global scope, and so running type-checkers completely independently would be wasteful – both in computation and memory.\nOn the other hand, type-checking occasionally relies on the relative ordering of information in a program, and so type-checking from scratch must always check the same files in an identical order to ensure the same results.<\/p>\n
To enable parallelization while avoiding these pitfalls, TypeScript 7.0 creates a fixed number of type-checker workers with their own view of the world.\nThese type-checking workers may end up duplicating some common work, but given the same input files, they will always divide them identically and produce the same results.<\/p>\n
The default number of type-checking workers is 4, but it can be configured with the new --checkers<\/code> flag.\nYou may find that increasing this number can further speed up builds on larger codebases where typical machines have more CPU cores, but will typically come at the cost of increased memory usage.\nLikewise, machines with fewer CPU cores and less memory (e.g. CI runners) may want to decrease this number to avoid unnecessary or incidental overhead.<\/p>\n
In rare cases, varying the number of --checkers<\/code> may surface order-dependent results.\nSpecifying a fixed number of checkers across build environments can help ensure everyone is getting the same results, but is up to the discretion of each team.<\/p>\n
Project Reference Builder Parallelization<\/h3>\n
TypeScript 7.0 can parallelize builds within a project, but it can now also build multiple projects at once as well.\nThis behavior can be configured with the new --builders<\/code> flag, which controls the number of parallel project reference builders that can run at once.\nThis can be particularly helpful for monorepos with many projects.<\/p>\n
Like --checkers<\/code>, increasing the number of builders can speed up builds, but may come at the cost of increased memory usage.\nIt also has a multiplicative effect with --checkers<\/code>, so it’s important to find the right balance for your machine and codebase.\nFor example, building with --checkers 4 --builders 4<\/code> allows up to 16 type-checkers to run at once, which may be excessive.<\/p>\n
Unlike --checkers<\/code>, varying the number of builders should not produce different results;\nhowever, building project references is fundamentally bottlenecked by the dependency graph of projects (with the exception of type-checking on codebases that leverage --isolatedDeclarations<\/code> and separate syntactic declaration file emit).<\/p>\n
Single-Threaded Mode<\/h3>\n
In some cases, it can be helpful to enforce single-threaded operation throughout the compiler.\nThis may be useful for debugging, comparing performance with TypeScript 6 and 7, when orchestrating parallel builds externally, or for running in environments with very limited resources.\nTo enable single-threaded mode, you can use the new --singleThreaded<\/code> flag.\nThis will not only cap the number of type-checking workers to 1, but also ensure parsing and emitting are done in a single thread.<\/p>\n
Improved --watch<\/code> Mode<\/h2>\n
Worth calling out is TypeScript 7’s rebuilt --watch<\/code> mode.\n--watch<\/code> is now built on a new foundation derived from the Parcel bundler’s file-watcher<\/a> that provides efficient and stable cross-platform file watching capabilities.<\/p>\n
When our team set out to port our file watching logic, we encountered a few challenges with cross-platform file watching in Go.\nThe standard library doesn’t provide a built-in file watching API, and existing third-party libraries we explored had various issues with stability, performance, cross-platform support, or issues with build tooling integration.\nWe were able to build solutions around polling periodically to check for file changes, and this worked broadly across operating systems;\nhowever it was computationally expensive, especially at larger-scale projects with many dependencies in node_modules<\/code>.\nEven with dynamic scheduling strategies, we found that pure-polling solutions were too taxing for general use.<\/p>\n
For many years, Visual Studio Code has relied on @parcel\/watcher<\/code><\/a>, and in recent years TypeScript in VS Code has relied on its file watching capabilities indirectly.\nWhile it seemed promising, one of the problems for us with Parcel’s watcher is that it’s written in C++, and in turn requires a full C++ toolchain to build.\nGiven our positive experience with Parcel’s watcher in VS Code, we explored porting it to Go with a few minimal assembly shims to avoid introducing a new toolchain dependency.<\/p>\n
The exploration has been a success – what started as a very direct translation from C++ to Go was further refined into idiomatic Go that still passes the ported test suite.\nThe watcher is a self-contained package that has allowed us to keep a clean separation of concerns between what we care to watch and why.\nWe are now seeing significant resource improvements in --watch<\/code> mode across platforms, and have been hearing positive feedback from earlier users of TypeScript 7.<\/p>\n
We’d like to extend our thanks to Devon Govett whose work on Parcel has provided immense benefits to both the Visual Studio Code and TypeScript projects.\nWe hope this port will provide opportunities and insights for the original Parcel watcher codebase over time.<\/p>\n
Updates Since 5.x, and New Behaviors from 6.0<\/h2>\n
TypeScript 7.0 is made to be compatible with TypeScript 6.0’s type-checking and command-line behavior.\nPractically any TypeScript code that compiles cleanly with TypeScript 6.0 (with the stableTypeOrdering<\/code> flag on, and without any ignoreDeprecations<\/code> flag set) should compile identically in TypeScript 7.0.<\/p>\n
With that said, TypeScript 7.0 adopts 6.0’s new defaults, and provides hard errors in the face of any flags and constructs deprecated in TypeScript 6.0.\nThis is notable as 6.0 is still relatively new, and many projects will need to adapt to its new behaviors.\nWe encourage developers to adopt TypeScript 6.0 to make the transition to TypeScript 7.0 easier, and you can also read the TypeScript 6.0 release blog post<\/a> for more details on these deprecations.<\/p>\n
At a glance, the notable default changes to configuration are:<\/p>\n