TypeScript 7: The Native Go Compiler That Makes Your Builds 10x Faster

On July 8, 2026, the TypeScript team at Microsoft shipped TypeScript 7.0. This is not a routine feature release — it is the most significant infrastructure change in TypeScript's history: the compiler core has been completely migrated from TypeScript-on-JavaScript to a native Go implementation.

Codenamed Project Corsa, TypeScript 7 faithfully reproduces the original compiler structure in Go without altering type-checking logic, delivering 8x to 12x build speed improvements and up to 26% memory reduction.

Why Go?

For 14 years, the TypeScript compiler ran as TypeScript-compiled-to-JavaScript on Node.js, executing within V8. This architecture hit three hard ceilings:

1. Single-threaded bottleneck: V8's event loop cannot parallelize type-checking across files
2. JIT warmup penalty: V8's JIT needs runtime to reach peak performance, but compiler builds finish before optimal
3. GC thrashing: Large codebases generate massive temporary objects during type-checking, with GC pauses directly impacting throughput

Go's goroutine model, native compilation, and shared-memory multithreading solve all three.

The team chose Go over Rust or Zig for pragmatic reasons: Go is battle-tested in toolchain applications (Docker, Kubernetes, Terraform), compiles fast, deploys simply, and its restrained syntax is ideal for a faithful port rather than a rewrite.

Benchmarks: From Waiting to Instant

Microsoft published comparisons across well-known open-source projects. Default configuration (4 type-checker workers):

Project	TypeScript 6	TypeScript 7	Speedup
VS Code	125.7s	10.6s	11.9x
Sentry	139.8s	15.7s	8.9x
Bluesky	24.3s	2.8s	8.7x
Playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

With --checkers 8, VS Code drops further to 7.51 seconds — an astonishing 16.7x speedup.

Memory also improved:

Project	TS 6	TS 7	Reduction
VS Code	5.2GB	4.2GB	-18%
Bluesky	1.8GB	1.3GB	-26%
tldraw	0.6GB	0.5GB	-15%

Editor responsiveness is where the impact is most visceral. Opening an error file in the VS Code codebase: TypeScript 6 took 17.5 seconds to display the first diagnostic. TypeScript 7 takes under 1.3 seconds — over 13x faster.

Industry Feedback: Beyond the Numbers

• Slack: 40% reduction in merge queue time. CI type-checking went from 7.5 minutes to 1.25 minutes. Engineers described the previous editor language service as "almost unusable" — TypeScript 7 made local type-checking feasible again.
• Microsoft News Services: Saved 400 hours per month in CI wait time.
• Canva: First error display dropped from 58 seconds to 4.8 seconds.
• Vanta: Up to 9x faster builds on their largest project.
• PowerBI engineers: Called the TypeScript 7 editor experience "life-saving."

Parallelization Architecture: --checkers and --builders

TypeScript 7 introduces two new flags:

--checkers: Parallel Type-Checking

Defaults to 4 workers. Each worker maintains its own type view and processes assigned files in parallel. Results are deterministic given identical input files.

• Increase for more CPU cores — faster builds at the cost of memory
• Decrease to --checkers 1 in CI environments to avoid overhead
• Fix the value across build environments to prevent order-dependent results

--builders: Parallel Project Reference Building

Works with --build to control concurrent project reference builds. Critical for monorepos.

Note the multiplicative effect: --checkers 4 --builders 4 means up to 16 concurrent type-checkers, which may be excessive.

A new --singleThreaded flag forces serial execution for debugging or constrained environments.

Rewritten --watch Mode

TypeScript 7 ships a rebuilt file watcher, porting Parcel's @parcel/watcher from C++ to Go. The port uses minimal assembly shims, passes the original test suite, and eliminates the C++ toolchain dependency. Pure-polling solutions proved too expensive at scale; the native watcher solves this definitively.

Coexisting with TypeScript 6

TypeScript 7.0 ships without a programmatic API. Tools like typescript-eslint still need the TypeScript 6 API. The API returns in 7.1. Until then, side-by-side installation:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

npx tsc uses TypeScript 7 by default, while tools depending on the typescript package API use 6.0. The @typescript/typescript6 compatibility package provides a tsc6 binary and the full 6.0 API.

Breaking Changes Inherited from 6.0

TypeScript 7.0 is fully compatible with 6.0, but inherits its defaults and deprecations:

• strict defaults to true
• module defaults to esnext
• target: es5 and downlevelIteration removed
• moduleResolution: node/node10/classic removed — use nodenext or bundler
• baseUrl removed — paths is now relative to project root
• rootDir defaults to ./ — inner source directories must be explicit
• types defaults to [] — list global declaration dependencies explicitly

Vue / Svelte / Astro Users

Due to the missing API in 7.0, full editor support for Vue, Svelte, Astro, and MDX awaits 7.1. These frameworks can continue using TypeScript 6 via the side-by-side setup for type-checking while enjoying 7.0's speed elsewhere.

Migration

For most projects, upgrading is a single step:

npm install -D typescript@latest

The prerequisite: your project must already compile cleanly on TypeScript 6.0. If you are still on 5.x, migrate to 6.0 first to adjust to the new defaults, then move to 7.0.

TypeScript 7 is not a new toy. It is the most profound compiler engineering transformation in 14 years: from V8 to Go, from single-threaded to multi-core parallel, from waiting to instant. For anyone who types tsc every day, this may be the most tangible DX improvement of the year.