
TypeScript 7.0 is here: the Go-native compiler and what its 10x speed-up means
- VersionDude
- Tooling
- 7 min read
TypeScript 7.0 shipped on 8 July 2026 with a compiler rewritten in Go, and Microsoft's benchmarks put builds around 10x faster. What actually changed, why it is faster, and what to check before you migrate.
On 8 July 2026, Microsoft shipped TypeScript 7.0, the first stable release built on a compiler written in Go rather than JavaScript. It is the largest change in the language's history: the type checker and compiler that millions of projects depend on now run as native code, and Microsoft's published benchmarks put full builds roughly 8 to 12 times faster than the previous version.
The project has a long runway. Microsoft announced it in March 2025 under the codename Project Corsa, referring to the existing JavaScript-based codebase as Strada. A beta arrived in April 2026, a release candidate on 18 June 2026, and the generally available 7.0 release on 8 July 2026. The headline claim throughout has been the same: a roughly tenfold speed-up in type checking and compilation.
The numbers Microsoft published are concrete. Compiling the Visual Studio Code codebase dropped from about 77.8 seconds to 7.5 seconds, a 10.4x improvement, and Playwright fell from 11.1 seconds to 1.1 seconds. Real projects will vary, but the pattern across Microsoft's benchmark set clusters around the tenfold mark.
Two things account for the speed. About half comes from running as compiled native code instead of JavaScript executed by Node. The other half comes from shared-memory concurrency: the Go implementation can spread type-checking work across multiple CPU cores using shared memory, something the single-threaded JavaScript version could not do cleanly.
Importantly, this is a port, not a rewrite. Microsoft translated the existing compiler logic into Go while preserving the same type-checking behaviour, so the goal is that your code type-checks identically, with the same errors in the same places, just far faster. The team has said Go was chosen partly because its syntax and structure map closely to the existing JavaScript code, which made a faithful port feasible for both people and tools.
For day-to-day work, the payoff is felt in two places. Editors become more responsive on large codebases, because the language service behind features like autocomplete, go-to-definition and error underlines is doing the same work in a fraction of the time. And continuous-integration pipelines that run the compiler on every commit get shorter, which matters most for large monorepos where type checking had become a real bottleneck.
If you are planning to adopt it, treat the move as a compatibility check rather than a rewrite of your own code. Because semantics are preserved, most projects should see no change in the errors reported. Still, verify against your actual build: check that your tsconfig options, build scripts and any custom tooling that hooks into the TypeScript API behave as expected. Consult the official release notes for the exact opt-in path and any documented caveats before switching a production pipeline.
The release also fits a wider trend. The JavaScript toolchain has spent several years moving performance-critical tools to native languages: bundlers and transpilers written in Go and Rust, such as esbuild and the SWC and Biome family, have set the expectation that core tooling should be near-instant. TypeScript's own type checker had remained one of the last big pieces still running in JavaScript, and TypeScript 7.0 closes that gap.
The bottom line: TypeScript 7.0 does not change how you write TypeScript, but it changes how it feels to work with at scale. If slow type checks or sluggish editor performance had become a tax on a large project, this release is aimed squarely at that pain, and the measured speed-ups are large enough to be worth planning a migration around.


