TypeScript 7.0 ships a compiler rewritten in Go, with 8-12x faster builds

Microsoft shipped TypeScript 7.0 on July 8, 2026, and with it replaced the compiler that has powered the language since its inception. According to a dev.to write-up, the new compiler is written in Go, developed under the internal codename Corsa, and it ships no new syntax, operators or language features. The entire release is architectural: compiled native code and real multithreading in place of interpreted JavaScript running on a single thread.

Why the old compiler hit a ceiling

The original compiler, language service and type checker were all written in TypeScript and executed single-threaded inside Node.js. As dev.to explains, type-checking is CPU-bound and, in principle, highly parallelizable, since files and sections of a project can largely be checked independently. A single-threaded runtime could not exploit that, leaving extra cores idle during checks on CI runners and developer machines alike, while JIT warm-up costs penalized the constant fresh-start invocations typical of editor tooling and CLI use.

A faithful port, not a redesign

Microsoft evaluated C#, Rust and Go before settling on Go. Per the dev.to account, lead architect Anders Hejlsberg framed the choice as picking the lowest-level language that still offered full native-code builds on every platform TypeScript targets, along with strong built-in concurrency. Go's goroutines and channels map neatly onto the problem of checking many files in parallel and merging the results, without the steeper learning curve or borrow-checker overhead a Rust port would have imposed on a team migrating an enormous existing codebase.

Notably, the team did not start from a blank page. The existing compiler was ported as faithfully as possible, specifically to keep results consistent between the old and new implementations and avoid subtle type-checking differences.

The performance numbers

Microsoft's headline figure, as relayed by dev.to, is an 8x to 12x speedup on full builds for large real-world projects, driven by native execution, shared-memory multithreading and targeted optimizations. Reported specifics include:

• A full type-check of the VS Code codebase fell from roughly 125 seconds to about 10.6 seconds.
• VS Code's language service became usable in about 1.2 seconds, down from roughly 9.6 seconds.
• Peak memory usage dropped by 6% to 26%, depending on project size.
• Microsoft internally reported a 20x reduction in failing language server commands compared with TypeScript 6.0, a proxy for timeouts, hangs and stale results on large projects.
• At Slack, engineers who previously could not run a full type-check locally and offloaded it to CI can now run it on a laptop.

Parallelism flags and a separate binary

TypeScript 7.0 introduces genuine shared-memory multithreading with knobs to control it. A checkers flag sets the number of type-checking workers, a builders flag runs multiple project-reference builders concurrently in monorepos, and a single-threaded mode disables parallelism for debugging or behavior comparisons. dev.to notes Microsoft's guidance that combining the checker and builder settings multiplies active workers rather than adding them, so the right values depend on the machine and project shape.

The Go compiler ships as a separate binary, distributed during the preview period as @typescript/native-preview before being folded into the mainline typescript package. The recommended migration is incremental rather than a hard switch: run the native binary alongside the existing tsc, diff their diagnostics in CI for a few weeks, and cut over once the outputs line up.

Editor tooling moves to LSP

The language server was rewritten too, on a Language Server Protocol foundation that is not tied to VS Code, meaning any LSP-compatible editor can adopt it. VS Code users can opt in through the TypeScript Native Preview extension, while Visual Studio auto-enables TypeScript 7 based on workspace configuration.

Caveats before upgrading

dev.to describes the migration as young and fast-moving and warns that the programmatic API is unstable. Build tooling, linters and custom scripts that call the TypeScript compiler API directly face the largest adjustment, since they must track the new native implementation rather than the JavaScript one they were written against.

Why it matters

TypeScript's compile step sits in the critical path of nearly every TypeScript project, both in the editor and in CI. An 8x to 12x reduction in type-check time turns minutes-long waits into seconds, directly cuts CI minutes, makes autocomplete and diagnostics usable far sooner on large codebases, and finally puts multi-core hardware to work during checks. The faithful-port strategy and side-by-side migration path are what make such a wholesale replacement of a mature tool viable at all. It is also a consequential shift for the wider ecosystem: performance arrives as the headline feature, while tooling built directly on the compiler API now has a new foundation to adapt to.