TypeScript 7 Rewrote Its Compiler in Go — And It's 10x Faster

I’ll admit something: when I first heard TypeScript was being ported to Go, I rolled my eyes. Another rewrite. Another “10x faster” claim that means nothing on my 200-line side project.

Then I ran the beta on our actual codebase — 47,000 lines of TypeScript across a monorepo with 12 packages. tsc on TS 6 took 14.2 seconds. tsgo on TS 7 took 1.4 seconds.

Ten times. Not nine, not eleven. Ten.

And the thing that really got me? The type-checking behavior is structurally identical. This isn’t a ground-up rewrite with new semantics. It’s the same TypeScript you know, just finally running on a runtime that doesn’t fight the event loop.

The Numbers Don’t Lie

Microsoft didn’t just benchmark this on a toy example. Here are the real numbers from their own testing across codebases you’ve probably heard of:

Codebase	Lines of Code	TS 6	TS 7 (Go)	Speedup
VS Code	1,505,000	77.8s	7.5s	10.4x
Playwright	356,000	11.1s	1.1s	10.1x
TypeORM	270,000	17.5s	1.3s	13.5x
date-fns	104,000	6.5s	0.7s	9.5x
tRPC	18,000	5.5s	0.6s	9.1x

Even the smallest codebase (rxjs at 2,100 lines) went from 1.1s to 0.1s — 11x faster. The speedup isn’t just for mega-repos.

IDE responsiveness got the same treatment. Project load times dropped ~8x across the board. “Find All References” and “Go to Definition” — the two operations I use hundreds of times per day — are now essentially instant.

Why Go? Why Now?

TypeScript’s compiler has been written in JavaScript since 2012. That made sense then: dogfooding your own language is good practice, and the compiler wasn’t that complex.

Fourteen years later, the TypeScript compiler is over a million lines of code checking other people’s codebases that are also millions of lines. The JavaScript runtime — single-threaded, garbage-collected, event-loop bound — was never designed for this workload.

The Go port changes the execution model entirely:

┌─────────────────┐          ┌──────────────────┐
│   TS 6 (JS)     │          │   TS 7 (Go)      │
├─────────────────┤          ├──────────────────┤
│ Single-threaded │   →      │ Native threads   │
│ Event loop      │          │ Shared memory    │
│ GC pauses       │          │ No GC (Go has    │
│ Process-bound   │          │   GC but it's    │
│                 │          │   concurrent)    │
└─────────────────┘          └──────────────────┘

Microsoft didn’t rewrite the compiler — they ported it. The type-checking logic is structurally identical to TS 6.0. Same rules, same errors, same output. Just running on a fundamentally faster engine.

The new Go compiler also supports native parallelism out of the box. Parsing, type-checking, and emitting now run concurrently across CPU cores. You can tune it:

{
  "compilerOptions": {
    "--checkers": 4,      // type-checker worker count (default: 4)
    "--builders": true     // parallel project-reference builds
  }
}

On a 16-core machine, bumping --checkers to 8 shaved another 15% off our monorepo build. The trade-off? Higher memory usage. On a 2-core CI runner, I’d leave it at default or even try --singleThreaded to reduce overhead.

This Validates Our Bifurcation Thesis

When I wrote about TypeScript 6 last month, I argued that TypeScript was splitting into two paradigms: erasable TS (Node.js type stripping, no build step, annotations only) and full TS (decorators, transforms, compile-time features).

TypeScript 7 doesn’t contradict this thesis — it accelerates it.

With TS 7, the “full TS” path just got dramatically faster. The compilation step that people complained about as the tax of TypeScript? It went from “noticeable friction” to “barely perceptible.”

Here’s what this means in practice. Our current monorepo setup:

# Before (TS 6): CI pipeline
$ time tsc --build           # 14.2s — long enough to context-switch
$ time biome check src/      #  0.8s — already fast
$ time vitest run            #  3.1s
# Total: ~18s

# After (TS 7): Same pipeline
$ time tsgo --build          #  1.4s — gone before I finish my sip
$ time biome check src/      #  0.8s
$ time vitest run            #  3.1s
# Total: ~5.3s

The compilation step is no longer the bottleneck. The tests are. That’s a fundamentally different developer experience — one where type-checking feels free instead of expensive.

What Actually Changes (And What Breaks)

This isn’t a drop-in replacement with zero friction. TypeScript 7 brings stricter defaults and drops legacy support. Here’s what’s different:

New Defaults (no config needed)

• strict: true — always on now
• module: "esnext" — no more commonjs default
• types: [] — empty array, no more implicit @types inclusion
• stableTypeOrdering: true — cannot be disabled

Hard Errors (your old config will break)

• target: "es5" — gone
• moduleResolution: "node" / "node10" — gone
• module: "amd", "umd", "systemjs", "none" — gone
• esModuleInterop: false — no longer allowed
• downlevelIteration: true — gone

If your project targets ES5 (looking at you, legacy Angular apps), you’ll need to upgrade your target before TS 7. If you’re still on node module resolution — which most pre-2024 projects are — you’ll need to migrate to node16 or bundler.

Getting Started

The beta uses a separate package name so you can test it side-by-side with TS 6:

# Install the beta
npm install -D @typescript/native-preview@beta

# Run the new compiler (note: tsgo, not tsc)
npx tsgo --version
# Version 7.0.0-beta

# Your tsconfig.json works as-is (unless you use deprecated options)
npx tsgo --build

For VS Code, there’s the TypeScript Native Preview extension. Daniel Rosenwasser from the TypeScript team called it “rock-solid.” I’ve been using it for two weeks and haven’t hit a single IDE crash.

When TS 7 goes stable, the package name reverts to typescript and the binary goes back to tsc. The beta naming is temporary — it exists so ecosystem tools can prepare.

Common Objections (I’ve Had Them Too)

Concern	Reality
”Go? Really? Why not Rust?”	Go’s standard library, GC, and cross-compilation story made it the pragmatic choice. Performance is already 10x. This isn’t a systems programming contest.
”It’s beta, I’ll wait”	Microsoft’s own words: “Don’t let the beta label fool you — you can probably start using this in your day-to-day work immediately.” It’s been tested at Bloomberg, Figma, Linear, Notion, Slack, and Vercel.
”Our codebase uses ES5”	Time to upgrade. TS 7 drops ES5 support. But TS 7’s compiler is so fast that transpiling to ES2020 with a separate tool (esbuild, swc) is still faster than TS 6 compiling to ES5.
”What about the programmatic API?”	Delayed until TS 7.1. If you use typescript as a library (eslint-plugin, custom transformers), stay on TS 6 for now. The @typescript/typescript6 compat package exists for this transition.
”Will this break our CI?”	Only if you use deprecated tsconfig options. Run tsgo --build in parallel with tsc --build first, compare outputs, then switch. The risk is config compatibility, not correctness.

Where TypeScript Stands Now

Let me zoom out. In the last 12 months, TypeScript has:

1. Erased the build step (TS 6 — erasable syntax, Node.js type stripping)
2. Erased the compilation wait (TS 7 — Go compiler, 10x faster)
3. Replaced ESLint + Prettier (Biome v2 — type-aware linting in Rust)

These aren’t three separate stories. They’re one story: TypeScript is removing every reason to complain about it.

No build step. No slow compilation. No bloated toolchain. The friction that kept teams on plain JavaScript is gone.

I wrote last month that TypeScript 6 was the beginning of a bifurcation — erasable TS for fast iteration, full TS for advanced features. TypeScript 7 makes the “full TS” path fast enough that the bifurcation matters less. Both paths are now compelling.

My Take

If you’re starting a new TypeScript project today, install @typescript/native-preview and use it from day one. The 10x speedup isn’t just a convenience — it changes how you interact with the compiler. You’ll run type-checks more often because they’re free. You’ll catch errors earlier because the feedback loop is instant.

If you’re on a legacy codebase, run tsgo alongside tsc this week. Fix the deprecated config options. The migration is mostly tsconfig.json surgery, not code rewrites. And once you feel that 10x speedup on your own codebase, you won’t want to go back.

The TypeScript team didn’t just make the compiler faster. They made the developer experience effortless. And that’s the kind of change that doesn’t just improve your CI — it changes how you write code.

---