TypeScript's Native Go Compiler Is Now Testable: What tsgo Changes for Your Build

If your TypeScript builds feel slow, there's something you should try right now.

Microsoft released TypeScript Native Previews on May 22 — the Go-based rewrite of the TypeScript compiler that's been in development under Project Corsa. This isn't TypeScript 7.0 final. It's a preview. But it's far enough along that you can run it against real projects and see what breaks (or doesn't), and the performance numbers are the kind that make you re-read the sentence twice.

What tsgo Actually Is

The original TypeScript compiler (tsc) is written in TypeScript/JavaScript. It runs on Node.js, it's single-threaded, and it accumulates I/O and GC overhead at scale. That's been the hard ceiling on compile performance for years — you could tweak skipLibCheck, add project references, fiddle with incremental, and still watch large monorepos grind through 90-second type checks.

tsgo is a new binary written in Go. It uses goroutines for parallel type checking, carries no Node.js startup overhead, and has none of the garbage collection pressure that slows tsc down on large projects. Microsoft has been running it against their test suite and the compatibility numbers land at **99.6%** — 19,926 out of 20,000 compiler test cases passing.

The compile speed improvements they've published are on real production codebases:

• VS Code (1.5 million lines of TypeScript): **78 seconds → 7.5 seconds**

• Sentry: **133 seconds → 16 seconds**

• Editor startup for the VS Code project: **9.6 seconds → 1.2 seconds**

Those aren't synthetic benchmarks tuned to make a slide look good. Those are projects the whole industry uses.

How to Try It Right Now

Install the preview package and run it:

bash npm install -D @typescript/native-preview npx tsgo --version

Then run a type check against your project:

bash npx tsgo --noEmit

If you're on VS Code, there's a dedicated extension. Install it, flip the language service to tsgo in your workspace settings, and you'll immediately notice faster autocomplete and error highlighting on anything larger than a medium-sized codebase.

For CI, the simplest evaluation is replacing tsc --noEmit with tsgo --noEmit in a parallel job and comparing results.

Why the Gap Exists

The architecture difference is straightforward:

mermaid flowchart LR A[.ts files] --> B[tsc on Node.js] B --> C[serial parse] C --> D[serial check] D --> E[.js output] A --> F[tsgo in Go] F --> G[parallel parse] G --> H[parallel check] H --> I[fast .js output]

tsc processes files with a single JavaScript event loop. File A has to finish before file B can start. tsgo spins up goroutines and checks across files concurrently, which is why editor startup improves so dramatically — it doesn't have to hold back behind one slow file before indexing the rest of the project.

The Go runtime's low-latency memory model also means tsgo doesn't pause mid-check for garbage collection the way a long-running Node.js process will. On big projects, those pauses aren't rare.

What's Still Missing

This is a preview, so the gaps are real. Declaration emit — the --declaration flag that generates .d.ts files — is still in progress. A subset of tsconfig.json options aren't fully wired up. Some language service features exposed to editors (specific refactoring actions, a handful of code actions) are not yet implemented.

The 0.4% test suite gap (74 failing tests) is small but not zero. If you hit failures, they're likely to appear in:

• Complex conditional type inference chains

• Template literal types inside deeply nested generics

• allowJs and mixed JS/TS project configurations

• Certain paths alias setups with project references

Pure TypeScript projects with a straightforward tsconfig.json will mostly sail through. Projects doing unusual things with composite builds or heavy allowJs usage should budget time to investigate.

What Your Team Should Actually Do This Week

**Run the type check and diff the output.** One command tells you where you stand:

bash npx tsgo --noEmit 2>&1 | tee tsgo-output.txt diff <(npx tsc --noEmit 2>&1) tsgo-output.txt

Anything in the diff is worth noting. False positives from tsgo (errors it reports that tsc doesn't) are the most important — those are exactly what the TypeScript team needs reports on.

**Benchmark your CI type-check step.** Most teams have a tsc --noEmit step sitting between 10 and 120 seconds depending on project size. Time both, record the numbers. This is your baseline to validate when TypeScript 7.0 ships final.

**Do not switch emit to tsgo yet.** The --declaration path is incomplete. If your library build generates .d.ts files, keep tsc for that step. The safe pattern right now is: tsgo --noEmit for the type-check gate, tsc for everything that touches emit.

**File breakages upstream.** The TypeScript team is explicitly asking for real-world compatibility reports. If tsgo gives you a false error on valid code, that's a direct contribution to getting TypeScript 7.0 right. The GitHub repo is microsoft/TypeScript.

Should You Be Excited?

Yes, but calibrate the excitement to your project size. For a 20-file side project, tsgo is faster but it won't feel like a revelation — you're shaving a couple seconds off a check that was already fast.

For monorepos, large enterprise TypeScript codebases, or any team that runs tsc in watch mode for hours every day — this is the performance unlock that no config change could ever deliver. A 10x build time reduction means the feedback loop in local development actually changes. That's not a small thing.

The preview is stable enough to evaluate seriously. It's not stable enough to replace tsc in production builds today. That's exactly where a responsible preview should be — usable enough to give real signal, honest enough to tell you what's not done yet.

Run the diff. Record your benchmark. You'll want both numbers when TypeScript 7.0 hits.