TypeScript 7.0 RC: The Compiler Now Runs on Go, and It's Fast

On July 8, 2026, Microsoft shipped TypeScript 7.0 RC. The version number makes it sound like a language release, but it isn't one. The compiler core—the thing that parses your code, builds the type graph, and spits out errors—has been ported from TypeScript to Go. The result: builds that run 8 to 12 times faster on real codebases.

I tried it on a mid-sized monorepo with about 800 TS files. tsc --noEmit went from 42 seconds to 4.3. That's not an incremental improvement. That's a different material.

Same Compiler, Different Engine

Let's get one thing out of the way: TypeScript 7.0 introduces zero new type system features and zero new syntax. No new utility types, no new inference rules, no new strictness flags. The type-checking logic is structurally identical to TypeScript 6.0.

The team emphasized this in the RC announcement: the Go codebase "was methodically ported from the existing implementation rather than rewritten from scratch." They ran it against roughly 20,000 test cases. In all but 74, TypeScript 7 produced the same errors as TypeScript 6.

This is a performance release wearing a major version number. Your types won't change. The inference you rely on won't shift. The edge cases you've memorized—they're all still there.

Why Go?

When Microsoft announced the port back in March 2025, the obvious question was: why Go and not Rust?

Anders Hejlsberg and the TypeScript team had a practical answer. A compiler is a graph of heavily interconnected, mutable data structures: type graphs, symbol tables, module resolution caches. You need multiple goroutines reading and writing to shared state concurrently. Go's goroutine and channel model, combined with its pragmatic approach to shared memory, maps naturally onto this problem.

Rust could absolutely do this, but the ownership model would demand layers of Arc<Mutex<>> or unsafe blocks around every shared data structure. The development velocity would suffer, and a compiler team needs to iterate fast. The team's calculus was straightforward: a compiler is internal tooling. It doesn't need to squeeze out every last nanosecond of runtime—it needs to be fast enough, maintainable, and easy to evolve. Go hits that balance.

There's also the distribution angle. A single statically-linked Go binary eliminates the Node.js binding headaches that plagued npm installs across platforms. One binary, no runtime dependency.

How Parallelism Actually Works

TypeScript 6.0 and earlier compilers were fundamentally single-threaded. Workers exist in JavaScript, but the shared memory constraints make fine-grained parallelism across a compiler's global state extremely difficult.

The Go version redesigns the build pipeline around concurrency. Parsing, type-checking, and emit can all run in parallel across files. Parsing is trivially parallelizable—each file is independent. Type-checking requires a dependency graph, but once that's built, files without circular dependencies can be checked simultaneously. Emit is naturally parallel.

Microsoft's phrasing was that the parallelism "automatically scales to larger codebases with low overhead." In my testing, the speedup ratio actually improves as file count grows. Eight hundred files gave me ~10x. Two thousand files might push past that.

The tradeoff is memory. The Go version peaks about 30-50% higher than the JS version. For CI runners, trading RAM for time is almost always a good deal. For local development, it's noticeable but manageable.

What Breaks When You Upgrade

The biggest breaking change isn't in your code—it's in your toolchain. TypeScript 7.0 ships without a stable programmatic API. That's coming in 7.1. If you have tools that import ts from 'typescript' and call ts.createProgram(), they will break on 7.0.

Microsoft provides a compatibility escape hatch: the @typescript/typescript6 package. It ships a tsc6 binary and re-exports the full TypeScript 6.0 API surface. The migration path is to install both typescript@7 (for the tsc command) and @typescript/typescript6 (for tsc6 and API consumers), then migrate your tooling to the stable API when 7.1 drops.

CI pipelines need attention too. If you run npx tsc --noEmit in CI, the command will be dramatically faster—but your caching strategy needs revisiting. The internal representation of ASTs and type graphs changed, so old caches are useless.

For editor integration, VS Code's TypeScript support needs an update to use the 7.0 language service. During RC, the recommended setup is 7.0 for builds and 6.0 for IDE support, controlled via workspace-level TypeScript version settings.

Timeline

Microsoft plans to ship the stable release within a month of RC, which puts it around early August 2026. The remaining work is release coordination, reported regressions, and API planning for 7.1.

My take: if your project doesn't deeply depend on the compiler API—and most don't—try the RC on a branch now. The build speed improvement is real and immediate. The type-checking behavior is nearly identical, so the regression risk is low. Switch fully when 7.1 brings the stable API, and migrate your remaining tooling then.

TypeScript didn't get faster. It got a faster engine. For anyone who's spent hours watching tsc crawl through a monorepo, that's about the best news you could ask for.