TypeScript 7.0 Is Rewriting the Compiler in Go

For most of its history, TypeScript has been written in TypeScript. The compiler, the language service, the checker — all JavaScript, all running on a single thread inside Node.js. That's changed now. TypeScript 7.0, shipped by Microsoft on July 8, 2026, replaces that entire implementation with a native compiler written in Go, developed under the internal codename Corsa.

There's no new operator, no new utility type, no new flavor of decorators to learn. The entire pitch is architectural. A compiler that runs as compiled native code instead of interpreted JavaScript, with real multi-threaded parallelism instead of a single-threaded event loop. If you've ever watched tsc --noEmit grind through a large monorepo, this release is aimed squarely at you.

Here's what actually changed, why Microsoft picked Go over Rust or its own C#, and what it means for your day-to-day workflow.

Why rewrite the compiler at all

The JavaScript-based compiler had hit a structural ceiling. Type-checking is CPU-bound and highly parallelizable in theory — different files and different parts of a project can be checked independently — but a single-threaded interpreted runtime can't take advantage of that. Every extra core sitting idle on a CI runner was wasted, and V8's JIT overhead only compounds on cold starts, which matter a lot for editor tooling and CLI invocations that start fresh constantly.

The TypeScript team weighed C#, Rust, and Go before settling on Go. Lead architect Anders Hejlsberg explained the reasoning as choosing the lowest-level language that still delivered full native-code support across every platform TypeScript needs to run on, with strong built-in support for concurrency. Go's goroutines and channels map cleanly onto the "check many files in parallel, then merge results" problem that type-checking actually is, without the steeper learning curve or borrow-checker overhead that a Rust port would have introduced for a team migrating an existing, enormous codebase.

Crucially, the Go port wasn't written from a blank page with a redesigned architecture. The team ported the existing compiler as faithfully as possible specifically to keep results consistent between the old and new implementations rather than risk subtle type-checking differences creeping in.

The performance numbers

The headline figure Microsoft is quoting is an 8x to 12x speedup on full builds for large, real-world projects, driven by native-code execution, shared-memory multithreading, and a set of targeted optimizations layered on top.

Independent benchmarks back this up with concrete examples rather than just multipliers:

• A full type-check of the VS Code codebase dropped from over two minutes to about ten seconds.
• Editor startup time for VS Code's language service — the delay before autocomplete and error-checking are usable — fell from roughly 9.6 seconds to about 1.2 seconds.
• Memory usage dropped as well, with reported reductions somewhere in the 6% to 26% range depending on project size.

• At Slack, engineers had previously been unable to run a full type-check locally at all and offloaded it to CI. With TypeScript 7, that check runs on a developer's laptop again.
  At a glance — TS 6.0 vs. TS 7.0:

• VS Code, full type-check: ~125s → ~10.6s (~12x faster)

• VS Code, language service ready: ~9.6s → ~1.2s (~8x faster)

• Typical large monorepo, full build: 8x–12x faster overall

• Peak memory usage: 6%–26% lower
  They're the kind of number that changes how a team works day to day: PRs that used to wait on a slow CI type-check come back faster, and the "let me just wait for the editor to catch up" pause before you start typing mostly disappears.

What's actually new under the hood

Native multithreading, with knobs to control it

The old compiler had no real concept of parallel type-checking; a single check ran on a single thread, full stop. TypeScript 7.0 introduces genuine shared-memory multithreading, along with flags to tune it:

# Use multiple type-checking workers
tsc --checkers 4

# Run multiple project-reference builders in parallel (monorepos)
tsc --builders 4

# Disable parallelism entirely — useful for debugging or
# comparing behavior against older TypeScript versions
tsc --singleThreaded

More checkers generally means faster type-checking at the cost of higher memory usage, so the right setting depends on your machine and your project's shape. For monorepos using project references, --builders lets multiple project builds run concurrently instead of serially, which is where a lot of the biggest real-world wins show up. Microsoft's own guidance is to be careful combining --checkers and --builders together, since the two multiply the number of active workers rather than add to it.

A new binary, not just a new flag

The Go compiler ships as a separate binary, distributed during the preview period as @typescript/native-preview on npm, with nightly builds available well before the tool was folded into the mainline typescript package. Getting started is close to a drop-in swap for most projects:

npm install -D typescript@latest

Teams migrating incrementally can install the native binary alongside the existing tsc and run both side by side to diff diagnostics before fully cutting over — which is exactly what Microsoft recommends rather than a hard, all-at-once switch. In practice that's a small, reversible change to your scripts rather than a rewrite of your build:

// package.json
{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "typecheck:native": "tsgo --noEmit --checkers 4"
  }
}

Run typecheck:native in CI alongside the existing script for a few weeks, diff the output, and once the diagnostics line up you can retire the old script and point your build pipeline at the native binary.

Editor tooling gets the same treatment

The language server, the part responsible for autocomplete, hover types, and inline errors in your editor, was rewritten too, built on a new Language Server Protocol foundation so it isn't tied to VS Code specifically. Any LSP-compatible editor should be able to pick it up. VS Code users can currently opt in through the TypeScript Native Preview extension, and Visual Studio will auto-enable TypeScript 7 based on workspace configuration. Internally, Microsoft has reported a 20x reduction in failing language server commands compared to TypeScript 6.0, a proxy for how often the old server would time out, hang, or return stale results on large projects.

What developers actually gain

Strip away the architecture talk and the concrete wins are:

• Faster feedback loops. Full project checks that took minutes now take seconds, which changes how often you're willing to run them.
• Snappier editors on large codebases. Faster startup and lower latency on autocomplete and diagnostics, particularly noticeable on monorepos and codebases in the tens-of-thousands-of-files range.
• Cheaper CI. Type-checking is frequently one of the slower steps in a JavaScript/TypeScript pipeline; an 8–12x reduction there has a direct, measurable effect on CI minutes and pipeline duration.
• Better use of the hardware you already have. Multi-core machines that were previously mostly idle during a type-check now get used, via --checkers and --builders.
• Lower memory pressure, which matters both on constrained CI runners and on developer laptops running an editor, a dev server, and a type-checker at once. ## What to know before upgrading

This is still a young, fast-moving migration, and there are real gaps worth knowing about before you commit a team to it:

• The programmatic API is unstable. If you have build tooling, linters, or custom scripts that call into the TypeScript compiler API directly rather than shelling out to tsc, that surface hasn't stabilized yet. Microsoft has indicated a stable programmatic API is targeted for TypeScript 7.1, not 7.0.
• The plugin and third-party tooling ecosystem is still catching up. Bundler integrations, editor plugins beyond the officially supported ones, and any tool that shells out to or embeds the old JavaScript compiler may need updates.
• Compatibility is strong but not perfect. In testing against large sets of real-world projects, TypeScript 7 flagged errors consistent with TypeScript 6 in the overwhelming majority of cases, but not literally all of them — a small number of projects saw new or different diagnostics surface, which is worth budgeting time to review if you're on a large codebase.
• This is a performance release, not a language release, despite the major version bump. If you're expecting new syntax or type-system features, they're not the point of 7.0. ## Should you upgrade now

For most teams, yes, with the incremental path Microsoft is recommending rather than a flip of the switch. Install the native compiler alongside your existing setup, run both against your codebase, diff the diagnostics, and confirm nothing unexpected shows up before replacing tsc in CI. If your project leans heavily on the programmatic compiler API for custom tooling, it's reasonable to wait for 7.1 before migrating that part of your stack, while still adopting the faster CLI and editor experience today.

The bigger story here isn't really about TypeScript specifically. It's part of a broader pattern across the JavaScript ecosystem — Rust-based bundlers, a Rust rewrite of pnpm, Bun's own move from Zig toward Rust — where tools that spent years as pure JavaScript are being rebuilt in compiled languages once JavaScript's single-threaded, interpreted nature becomes the actual bottleneck. TypeScript's compiler was arguably the biggest and most consequential piece of that puzzle still standing, and now it isn't.

For more such developer content, visit: vickybytes.com