Announcing TypeScript 7.0 Beta

Today we are absolutely thrilled to announce the release of TypeScript 7.0 Beta!

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. Over the past year, we have been porting the existing TypeScript codebase from TypeScript (as a bootstrapped codebase that compiles to JavaScript) over to Go. With a combination of native code speed and shared memory parallelism, TypeScript 7.0 is often about 10 times faster than TypeScript 6.0.

Don’t let the “beta” label fool you – you can probably start using this in your day-to-day work immediately. 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. This architectural parity ensures the compiler continues to enforce the exact same semantics you already rely on. TypeScript 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. It is highly stable, highly compatible, and ready to be put to the test in your daily workflows and CI pipelines today.

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. The 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. In turn, we feel confident that the beta is in great shape, and we can’t wait for you to try it out soon.

Using TypeScript 7.0 Beta

To get TypeScript 7.0 Beta, you can install it via npm:

npm install -D @typescript/native-preview@beta

Note: the package name will eventually be typescript in a future release.

From there, you can run tsgo in place of the tsc executable.

> npx tsgo --version
Version 7.0.0-beta

The tsgo executable has the same behavior on all TypeScript code as tsc from TypeScript 6.0 – just much faster.

To try out the editing experience, you can install the TypeScript Native Preview extension for VS Code. The editor support is rock-solid, and has been widely used by many teams for months now. It’s an easy low-friction way to try TypeScript 7.0 out on your codebase immediately. It 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. Notably, it’s also built on the language server protocol, making it easy to run in most modern editors or even tools like Copilot CLI.

Running Side-by-Side with TypeScript 6.0

To help you transition from TypeScript 6.0 to TypeScript 7.0, this beta release is available through the @typescript/native-preview package name using the tsgo entry point. This enables easy validation and comparison between tsc and tsgo.

However, as we mentioned above, the stable release of TypeScript 7.0 will be published under the typescript package and will use the tsc entry point.

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. Given 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 is which?”

As part of the 6.0/7.0 transition process, we’ve published a new compatibility package, @typescript/typescript6. This package exposes a new entry point tsc6, so that (if needed) you can run the next release of TypeScript 7.0 (which will provide a tsc binary) side-by-side without naming conflicts. It will also re-export the TypeScript 6.0 API, so that you can use tsc for TypeScript 7, while other tooling can continue to rely on 6.0.

Because some tools like typescript-eslint expect to import from typescript directly via peer dependencies, we recommend achieving this via npm aliases. You should be able to run the following command

npm install -D typescript@npm:@typescript/typescript6

or modify your package.json as follows:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
  }
}

In the future we will have more specific guidance for using a TS7-powered tsc alongside a TS6-powered tsc6.

Parallelization and Controls

TypeScript 7.0 now performs many steps in parallel, including parsing, type-checking, and emitting. Some of these steps, like parsing and emitting can mostly be done independently across files. As such, parallelization automatically scales well with larger codebases with relatively little overhead. But not every step in a TypeScript build is easily parallelizable.

Checker Parallelization

Other steps, like type-checking, have more complex dependencies across files. Most 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. On 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.

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. These 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.

The default number of type-checking workers is 4, but it can be configured with the new --checkers flag. You 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. Likewise, machines with fewer CPU cores (e.g. CI runners) may want to decrease this number to avoid unnecessary overhead.

In rare cases, varying the number of --checkers may surface order-dependent results. Specifying 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.

Project Reference Builder Parallelization

TypeScript 7.0 can parallelize builds within a project, but it can now also build multiple projects at once as well. This behavior can be configured with the new --builders flag, which controls the number of parallel project reference builders that can run at once. This can be particularly helpful for monorepos with many projects.

Like --checkers, increasing the number of builders can speed up builds, but may come at the cost of increased memory usage. It also has a multiplicative effect with --checkers, so it’s important to find the right balance for your machine and codebase. For example, building with --checkers 4 --builders 4 allows up to 16 type-checkers to run at once, which may be excessive.

Unlike --checkers, varying the number of builders should not produce different results; however, building project references is fundamentally bottlenecked by the dependency graph of projects (with the exception of type-checking on codebases that leverage --isolatedDeclarations and separate syntactic declaration file emit).

Single-Threaded Mode

In some cases, it can be helpful to enforce single-threaded operation throughout the compiler. This 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. To enable single-threaded mode, you can use the new --singleThreaded flag. This will not only cap the number of type-checking workers to 1, but also ensure parsing and emitting are done in a single thread.

Updates Since 5.x, and New Behaviors from 6.0

TypeScript 7.0 is made to be compatible with TypeScript 6.0’s type-checking and command-line behavior. Any TypeScript code that compiles cleanly with TypeScript 6.0 (with the stableTypeOrdering flag on, and without the ignoreDeprecations flag set) should compile identically in TypeScript 7.0.

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. This is notable as 6.0 is still relatively new, and many projects will need to adapt to its new behaviors. We 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 for more details on these deprecations.

At a glance, the notable default changes to configuration are:

strict is true by default.
module defaults to esnext.
target defaults to the current stable ECMAScript version immediately preceding esnext.
noUncheckedSideEffectImports is true by default.
libReplacement is false by default.
stableTypeOrdering is true by default, and cannot be turned off.
rootDir now defaults to ./, and inner source directories must be explicitly set.
types now defaults to [], and the old behavior can be restored by setting it to ["*"].

We believe the rootDir and types changes may be the most “surprising” changes, but they can be mitigated easily. Projects where the tsconfig.json sits outside of a directory like src will simply need to include rootDir to preserve the same directory structure.

  {
      "compilerOptions": {
          // ...
+         "rootDir": "./src"
      },
      "include": ["./src"]
  }

For the types change, projects that depend on specific global declarations will need to list them explicitly. For example,

  {
      "compilerOptions": {
          // Explicitly list the @types packages you need (e.g. bun, mocha, jasmine, etc.)
+         "types": ["node", "jest"]
      }
  }

The deprecations that have turned into hard errors with no-op behavior are:

target: es5 is no longer supported.
downlevelIteration is no longer supported.
moduleResolution: node/node10 are no longer supported, with nodenext and bundler being recommended instead.
module: amd, umd, systemjs, none are no longer supported, with esnext or preserve being recommended in conjunction with bundlers or browser-based module resolution.
baseUrl is no longer supported, and paths can be updated to be relative to the project root instead of baseUrl.
moduleResolution: classic is no longer supported, and bundler or nodenext are the recommended replacements.
esModuleInterop and allowSyntheticDefaultImports cannot be set to false.
alwaysStrict is assumed to be true and can no longer be set to false
The module keyword cannot be used in namespace declarations.
The asserts keyword cannot be used on imports, and must use the with keyword instead (to align with developments on ECMAScript’s import attribute syntax).
/// <reference no-default-lib /> directives are no longer respected under skipDefaultLibCheck.
Command line builds cannot take file paths when the current directory contains a tsconfig.json file unless passed an explicit --ignoreConfig flag.

JavaScript Differences

As we ported the existing codebase, we also took the opportunity to revisit how our JavaScript support works.

TypeScript originally supported JavaScript files by using JSDoc comments and recognizing certain code patterns for analysis and type inference. Lots of the time, this was based on popular coding patterns, but occasionally it was based on whatever people might be writing that Closure and the JSDoc doc generating tool might understand. While this approach was helpful for developers with loosely-written JSDoc codebases, it required a number of compromises and special cases to work well, and diverged in a number of ways from TypeScript’s analysis in .ts files.

In TypeScript 7.0, we have reworked our JavaScript support to be more consistent with how we analyze TypeScript files. Some of the differences include:

Values cannot be used where types are expected – instead, write typeof someValue
@enum is not specially recognized anymore – create a @typedef on (typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration].
A standalone ? is no longer usable as a type – use any instead.
@class does not make a function a constructor – use a class declaration instead.
Postfix ! is not supported – just use T.
Type names must be defined within a @typedef tag (i.e. /** @typedef {T} TypeAliasName */), not adjacent to an identifier (i.e. /** @typedef {T} */ TypeAliasName;).
Closure-style function syntax (e.g. function(string): void) is no longer supported – use TypeScript shorthands instead (e.g. (s: string) => void).

Additionally, some JavaScript patterns, like aliasing this and reassigning the entirety of a function’s prototype are no longer specially treated.

While some of our JS support is in flux, we have been updating this CHANGES.md file to capture the differences between TypeScript 6.0 and 7.0 in more detail.

Editor Experience

TypeScript 7.0’s performance improvements are not limited to the command line experience – they also extend to the editor experience too. The TypeScript Native Preview extension for VS Code provides a seamless way to try out TypeScript 7.0 in your editor, and has seen widespread use.

Since it first debuted, we’ve added in missing functionality like auto-imports, expandable hovers, inlay hints, code lenses, go-to-source-definition, JSX linked editing and tag completions, and more. Additionally, we’ve rebuilt much of our testing and diagnostics infrastructure to make sure the quality bar is high.

This extension respects most of the same configuration settings as the built-in TypeScript extension for Visual Studio Code, along with most of the same features. While a few things are still coming (like semantics-enhanced highlighting, more-specific import management commands, etc.), the extension is already powerful, stable, and fast.

Upcoming Work

In the coming weeks, we expect to ship a more efficient implementation of --watch, and meet parity on declaration file emit from JavaScript files. We will also be working on minor editor feature gaps like “find file references” from the file explorer, and surfacing the more granular “sort imports” and “remove unused imports” commands instead of just the more general “organize imports” command.

Beyond this, we’ll be developing a stable programmatic API for TypeScript 7.1 or later, improving our real-world testing infrastructure, and addressing feedback.

The Road to TypeScript 7.0

With TypeScript 7.0 Beta now available, the team is focusing on bug fixes, compatibility work, editor polish, and performance improvements as we move toward a stable release. Our current plan is to release TypeScript 7.0 within the next two months, with a release candidate available a few weeks prior. The release candidate will be the point where we expect TypeScript 7’s behavior to be finalized, with changes after that focused on critical fixes to regressions.

Between now and then, we would especially appreciate feedback from trying TypeScript 7.0 on real projects. If you run into any issues, please let us know on the issue tracker for microsoft/typescript-go so we can make sure the stable release is in great shape.

We also encourage you to share your experience using TypeScript 7.0 and tag @typescriptlang.org on Bluesky or @typescript@fosstodon.org on Mastodon, or @typescript on Twitter.

Our team is incredibly excited for you to try this release out, so try it today and let us know what you think. Happy hacking!

– The TypeScript Team