TypeScript 7's 10x Compiler Lands, With One Big Catch

Sixteen months after Anders Hejlsberg announced that Microsoft was porting the TypeScript compiler to Go and promised a 10x speedup, the promise has shipped. TypeScript 7.0, released July 8, is the first stable version built on the native compiler, and the announcement's benchmarks land almost exactly where Hejlsberg said they would: full builds run 8x to 12x faster. VS Code's 2.3-million-line codebase type-checks in 10.6 seconds instead of 125.7. Sentry drops from 139.8 seconds to 15.7. Playwright goes from 12.8 seconds to 1.47.

Those aren't microbenchmarks — they're the compiler eating some of the largest open TypeScript codebases in existence, and early adopters corroborate them. Slack reported CI type-checking falling from about 7.5 minutes to 1.25, and Microsoft's own News Services team claims roughly 400 engineer-hours a month recovered from waiting on CI. The speedup splits about evenly between native code and shared-memory multithreading, which is why it shows up in the editor too: on the VS Code codebase, surfacing errors in an open file went from 17.5 seconds to under 1.3.

This is a genuine toolchain shift, not a marketing release. But there's one catch big enough that many teams should wait a release cycle, and it's worth being precise about who's affected.

The last JavaScript tool written in JavaScript

The interesting question isn't whether Go is fast — it's why this took until 2026, and what it says about the ecosystem. Over the past five years, nearly every performance-critical piece of JS tooling was rewritten in a systems language: esbuild in Go, then swc, Biome, Oxc, Turbopack, and Rolldown in Rust. TypeScript itself was the giant holdout, a compiler written in the language it compiles, single-threaded on a JIT runtime that was never designed for CPU-bound batch work.

The ecosystem's workaround was to route around tsc entirely. Bundlers strip types with esbuild or swc and skip checking; Node now strips types natively at run time. That created today's awkward split: the fast path doesn't check your types, and the path that checks your types is too slow to run anywhere except CI — where teams like Slack were burning minutes per merge. TypeScript 7 collapses that split. It's not another type-stripper; it's the full checker, declaration emit and all, at native speed. Sub-2-second checks on half-million-line codebases mean type-checking can move back into pre-commit hooks and watch loops where it belongs.

The choice of Go over Rust drew grumbling in 2025, but it's why the project shipped in sixteen months. Hejlsberg's team didn't redesign the compiler — they ported it nearly function-for-function, which Go's garbage collector and structural style made feasible in a way a Rust rewrite wouldn't have been. A port, not a rewrite, is also why the 7.0 checker's behavior matches 6.0's: same inference, same errors, same output. That's the property that makes the 10x number trustworthy rather than a fresh-codebase asterisk.

The catch: no API until 7.1

TypeScript 7.0 ships without a stable programmatic API. That's not a small footnote. typescript-eslint's type-aware rules, Vue's vue-tsc, and the language tooling for Svelte, Astro, MDX, and Angular templates all drive the compiler through its API, and none of them can run against 7.0. Microsoft says the new API lands in 7.1, with releases planned every three to four months after.

In practice that means a large fraction of real-world projects can adopt 7.0 for builds but not for their whole toolchain. If you're on typescript-eslint with type-checked rules — which is most serious lint setups — you'll be running TypeScript 6 for lint and TypeScript 7 for tsc side by side. Microsoft ships a compatibility package for exactly this: npm install -D typescript@npm:@typescript/typescript6 keeps the old compiler and its API available under an alias while typescript points at 7. It works, but it's two compilers in your node_modules and two versions that can drift.

How to actually adopt it

The migration path is deliberate: 6.0 is the bridge release where old options became deprecations, and 7.0 turns them into hard errors. So upgrade to 6.x first, clear the warnings, then move.

The config breakage is real and mostly good. strict and module: esnext become defaults. Gone entirely: target: es5, baseUrl, moduleResolution: node10, downlevelIteration, and the AMD/UMD/SystemJS module formats. If you still ship ES5, TypeScript is officially out of that business — you'll transpile downstream with Babel or swc. baseUrl users need to convert to relative paths, and the new types: [] default means projects leaning on ambient global types must list them explicitly ("types": ["node", "jest"]). Budget a day for a mid-sized codebase, more if baseUrl imports are everywhere.

Once you're on 7, the new parallelism knobs matter for CI: --checkers (default 4) controls concurrent type-checking threads, --builders parallelizes project references. On a beefy CI runner, raising --checkers is free speed the old compiler could never offer.

Verdict

This is the most consequential TypeScript release since 2.0 shipped strict null checks, and the numbers survive scrutiny — they're consistent across Microsoft's benchmarks, third-party reporting, and named production adopters. The native-tooling wave has now claimed its final and largest target, and the practical ceiling on codebase size just moved by an order of magnitude.

The honest adoption call: if your toolchain is tsc plus a bundler, upgrade now — through 6.0, then straight to 7. If you depend on type-aware linting or framework language tooling, run 7 for builds via the compatibility alias and hold the full switch until 7.1 proves out the new API. Either way, stop designing your workflow around type-checking being slow. That constraint just expired.