TypeScript 7.0's Go Compiler: What Changed and How to Adopt It

TypeScript's compiler got a Go rewrite, and the result is not subtle: type-checking that took two minutes now takes ten seconds. TypeScript 7.0, released as version 7.0.2, is a native port of the existing compiler and language service from JavaScript to Go. Microsoft characterizes it as 8 to 12 times faster on full builds. Type-checking the VS Code codebase, for example, dropped from 125.7 seconds on TypeScript 6 to 10.6 seconds, an 11.9x speedup.

The important thing to understand up front: this is a port, not a redesign.

Key takeaways

• TypeScript 7.0 is a native Go port of the compiler, 8 to 12 times faster on full builds, with no new syntax or type-system changes.
• The blocker for many teams is tooling: there is no stable programmatic API yet, so ESLint, ts-jest, and Vue/Svelte/Astro integrations wait for 7.1.
• Adopt it in stages: run the new tsgo for speed, keep your current tsc in CI until your critical tooling supports 7.x.

What actually changed, and what did not

There is no new type system, no new syntax, and no new language features. The team took the existing checker (codenamed Strada) and methodically ported its logic to Go (the effort was Project Corsa), keeping it structurally identical. Your code type-checks the same way and means the same thing. It just resolves far faster, thanks to Go's concurrency and memory model rather than any change to what TypeScript is.

The payoff is felt at scale. On a small project you will not notice. On a large monorepo where slow tsc runs and a sluggish editor had become a tax, the difference is the whole point: faster CI, quicker editor feedback, less waiting.

How to get it

The native compiler now ships under the normal npm tag:

npm install -D typescript   # installs 7.0

Nightly builds moved from the standalone @typescript/native-preview package, which had passed 8.5 million weekly downloads before GA, into the standard typescript package under the next tag. The new compiler binary is tsgo.

The caveats that decide your timeline

This is where a staged rollout matters. A few things are not ready on day one:

• No stable programmatic API yet. Anything that drives the compiler through its API, and that is a large slice of the ecosystem, has to wait for 7.1. This is the single biggest blocker.
• Tooling lag. ESLint, ts-jest, and the Vue, Svelte, and Astro integrations were not ready at release and were waiting on 7.1. If your stack leans on typed linting or those frameworks, verify each before you switch.
• Stricter defaults. Strict mode and the TypeScript 6.0 deprecations become hard defaults in 7.0, so a migration can surface errors that 6.x tolerated.

How to adopt it in stages

Treat tsgo as an additive speedup, not a rip-and-replace:

1. Install 7.0 alongside your current setup and run tsgo on your codebase to see the raw type-checking time and surface any new strict-mode errors.
2. Keep your existing tsc in CI until the API-dependent tools you rely on (linter, test runner, framework plugin) confirm 7.x support.
3. Move CI and editors over once your critical tooling is green, framework by framework if you need to.

The bottom line

TypeScript 7.0 does not change how you write TypeScript. It changes how it feels to work with at scale. If slow type checks were never your problem, there is no urgency. If they were, the measured speedups are large enough to plan a migration around, as long as you sequence it behind the tooling you cannot live without. And if you want to skip the build step entirely for scripts and servers, that is a separate feature: running TypeScript directly in Node.js.