{"id":5152,"date":"2026-04-21T10:24:17","date_gmt":"2026-04-21T18:24:17","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/typescript\/?p=5152"},"modified":"2026-04-21T10:24:17","modified_gmt":"2026-04-21T18:24:17","slug":"announcing-typescript-7-0-beta","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-7-0-beta\/","title":{"rendered":"Announcing TypeScript 7.0 Beta"},"content":{"rendered":"

Today we are absolutely thrilled to announce the release of TypeScript 7.0 Beta!<\/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

Don’t let the “beta” label fool you – you can probably start using this in your day-to-day work immediately.\nThe 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 beta is in great shape, and we can’t wait for you to try it out soon.<\/p>\n

Using TypeScript 7.0 Beta<\/h2>\n

To get TypeScript 7.0 Beta, you can install it via npm:<\/p>\n

npm install -D @typescript\/native-preview@beta\r\n<\/code><\/pre>\n
Note: the package name will eventually be typescript<\/code> in a future release.<\/p><\/blockquote>\n
From there, you can run tsgo<\/code> in place of the tsc<\/code> executable.<\/p>\n
> npx tsgo --version\r\nVersion 7.0.0-beta\r\n<\/code><\/pre>\n
The tsgo<\/code> executable has the same behavior on all TypeScript code as tsc<\/code> from TypeScript 6.0 – just much faster.<\/p>\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, 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
To help you transition from TypeScript 6.0 to TypeScript 7.0, this beta release is available through the @typescript\/native-preview<\/code> package name using the tsgo<\/code> entry point.\nThis enables easy validation and comparison between tsc<\/code> and tsgo<\/code>.<\/p>\n
However, as we mentioned above, the stable release of TypeScript 7.0 will be published under the typescript<\/code> package and will use the tsc<\/code> entry point.<\/p>\n
Additionally, even though 7.0 Beta 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 exposes a new entry point tsc6<\/code>, so that (if needed) you can run the next release of TypeScript 7.0 (which will provide a tsc<\/code> binary) side-by-side without naming conflicts.\nIt will also re-export 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
In the future we will have more specific guidance for using a TS7-powered tsc<\/code> alongside a TS6-powered tsc6<\/code>.<\/p>\n
<\/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 (e.g. CI runners) may want to decrease this number to avoid unnecessary overhead.<\/p>\n
In rare cases, varying the number of --checkers<\/code> may surface order-dependent results.\nSpecifying a fixed number of checkers across your team 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
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.\nAny TypeScript code that compiles cleanly with TypeScript 6.0 (with the stableTypeOrdering<\/code> flag on, and without the 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