The TypeScript Go Compiler Is Here — What 10x Faster Type Checking Means for Your Codebase

The 10x Promise

Microsoft announced in March 2025 that the TypeScript compiler — one of the most widely used developer tools in the world — was being ported from TypeScript/JavaScript to Go. The headline number, a 10x speedup, dominated coverage. But a year later, with TypeScript 7.0 in beta and the Go-based tsgo compiler available on npm, the real picture is more nuanced. The 10x claim holds for large, I/O-bound codebases like VS Code (1.5 million lines, 77.8s to 7.5s), but drops to 1.6x for type-heavy libraries like type-fest. Understanding where your project falls on this curve is the difference between a smooth migration and a disappointing upgrade.

This article breaks down what the Go port actually changes, where the benchmarks land for different project profiles, what breaks in TypeScript 7.0, and a concrete migration strategy you can start today.

What Project Corsa Actually Is

The native port — codenamed Project Corsa, with the existing JS codebase called Strada — is not a rewrite. Anders Hejlsberg and the TypeScript team took the existing codebase and ported it line by line from TypeScript (which runs on Node.js) to Go. The type-checking logic is structurally identical. As the official announcement states, “the new Go codebase was methodically ported from our existing implementation rather than rewritten from scratch, and its type-checking logic is structurally identical to TypeScript 6.0” (per Microsoft’s TypeScript 7.0 Beta announcement). This architectural parity is the critical design decision: it means the compiler produces the same errors, the same types, and the same output — just faster.

The Go implementation gains speed from two sources: native compilation (no JIT warmup, no Node.js runtime overhead) and shared-memory parallelism. The current JS-based tsc is single-threaded; the Go version can parallelize type-checking across multiple cores with the --checkers flag, defaulting to 4 workers. The announcement benchmarks showed consistent 9 to 13.5x speedups on real projects, with VS Code dropping from 77.8 seconds to 7.5 seconds.

But a port is only as valuable as its compatibility. The TypeScript team validated Corsa against their decade-old test suite and against production codebases at Microsoft, Bloomberg, Canva, Figma, Google, Linear, Notion, Slack, and Vercel (per the TypeScript 7.0 Beta post). These aren’t toy projects — these are the codebases that broke the JS compiler’s limits.

The Benchmark Reality: 10x for Some, 1.2x for Others

Microsoft’s official benchmarks show impressive numbers across six popular open-source projects:

Codebase	Lines of Code	Current (JS)	Native (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
rxjs	2,100	1.1s	0.1s	11.0x

Source: Microsoft DevBlogs — “A 10x Faster TypeScript”

These are compelling, but they all share a characteristic: they are large codebases where module resolution, file I/O, and parsing dominate the type-checking time. That is where the Go compiler shines — loading thousands of files, resolving imports, and parsing ASTs is inherently parallelizable and benefits from native speed.

The independent benchmarks from a reproducible lab tell a different story for type-heavy libraries:

Corpus	TS6 median	TS7 median	Speedup
many-modules (2,600 files)	3,468 ms	858 ms	4.04x
template-literal-stress	44,009 ms	17,097 ms	2.57x
project-references	1,487 ms	622 ms	2.39x
ts-pattern v5.9.0	5,294 ms	2,795 ms	1.89x
type-fest v5.6.0	125,026 ms	76,685 ms	1.63x
ts-essentials v9.4.2	1,369 ms	1,164 ms	1.18x

When your codebase relies heavily on deeply recursive conditional types, mapped types, and template literal types — the kind of code that makes TypeScript valuable in the first place — the performance gain is real but modest. The inference algorithm runs the same logic; it just executes in Go instead of JavaScript. type-fest, a library famous for pushing the type system to its limits, gets only 1.63x faster. ts-essentials barely registers at 1.18x.

The implication: if your project is a monorepo with thousands of modules and straightforward types, you will see the 10x. If it is a small project with complex generic types, you will see 1.2 to 2x. Both are improvements, but they demand different upgrade urgency.

What Breaks in TypeScript 7.0

The Go port preserves type-checking semantics, but TypeScript 7.0 ships with new defaults and removes deprecated features that the 6.x series kept for backward compatibility. These are documented in the TypeScript 7.0 Beta changelog:

Hard removals (will produce errors):

• target: es5 — no longer supported
• downlevelIteration — removed
• moduleResolution: node / node10 — use nodenext or bundler
• module: amd, umd, systemjs, none — use esnext or preserve
• baseUrl — removed entirely; update paths relative to project root
• moduleResolution: classic — use bundler or nodenext
• esModuleInterop and allowSyntheticDefaultImports — cannot be false

New defaults that may surface hidden issues:

• strict: true — enabled by default (was opt-in)
• noUncheckedSideEffectImports: true — detects unused imports
• stableTypeOrdering: true — cannot be turned off; may change declaration ordering
• rootDir: "./" — inner source directories must be explicit
• types: [] — only explicitly listed @types packages are loaded

The baseUrl removal is the most painful for legacy projects. Many codebases rely on absolute imports like import { Thing } from "components/Button" resolved via baseUrl: "./src". In TypeScript 7.0, these must be rewritten to relative paths or handled through path mappings. The migration scanner from the independent benchmark lab checks for these exact issues and can be run against any project’s tsconfig.json.

Migration Strategy for Production Codebases

The TypeScript team designed the 6.x series as a transition layer specifically to ease this migration. TypeScript 6.0 introduces deprecation warnings for the features that 7.0 removes, giving you a full release cycle to fix them. As Daniel Rosenwasser wrote, “most users should think of [6.0] as a readiness check for adopting TypeScript 7.0” (per TypeScript 5.9 announcement).

Phase 1 — Audit (today): Upgrade to TypeScript 6.0 in your project and run tsc --noEmit. Fix every deprecation warning. The @typescript/typescript6 package provides a tsc6 binary so you can run TS6 and TS7 side-by-side. Remove baseUrl, migrate moduleResolution from node to bundler or nodenext, and audit target values.

Phase 2 — Test (this week): Install @typescript/native-preview@beta and run tsgo --noEmit in CI alongside your existing tsc. Compare the error output — it should be identical. If it is not, the discrepancies are bugs in the preview that the TypeScript team fixes actively. File them on the typescript-go issue tracker.

Phase 3 — Benchmark (profile your project): Run tsgo with --extendedDiagnostics to see parse time, bind time, check time, and memory usage. Compare against tsc on the same machine. If your project is module-heavy (many files, deep import chains), the 4 to 10x gain is immediate. If it is type-heavy (complex generics, recursive conditional types), the gain may be 1.2 to 2x. This tells you your actual upgrade urgency.

Phase 4 — Switch (once TS7 stable ships): The stable release will use the typescript package name and the tsc binary. At that point, drop the preview packages and depend on typescript@^7.0.0. If you still have tools that depend on the TS6 API, pin them to @typescript/typescript6 until those tools are updated.

The side-by-side installation pattern makes this safe:

{
  "devDependencies": {
    "@typescript/native-preview": "^7.0.0-dev.20260616.1",
    "@typescript/typescript6": "^6.0.1",
    "typescript": "^6.0.3"
  },
  "scripts": {
    "typecheck": "tsgo --noEmit",
    "typecheck:ts6": "tsc6 --noEmit"
  }
}

When NOT to Migrate Yet

The Go compiler is in beta, and some features are not ready. The GitHub repository lists the gaps:

• Language service API: Not ready. The stable programmatic API will not ship until TypeScript 7.1, several months after the initial release.
• JavaScript file support: In progress. JSDoc inference and declaration emit for .js files are incomplete.
• Watch mode: Prototype only. No incremental rechecking — it watches files and rebuilds from scratch.
• Declaration emit for JavaScript: Not complete.

If your project depends heavily on any of these features — particularly the programmatic API for build tooling or --watch for development — stay on TypeScript 6 until 7.1 ships. The migration audit (Phase 1) is still worth doing now, but the actual switch can wait.

The Editor Experience: Where 10x Matters Most

The command-line benchmarks get the headlines, but the editor experience is where most developers will feel the improvement. Project load time in VS Code drops from 9.6 seconds to 1.2 seconds — an 8x improvement (per the native port announcement). Every language service operation — completions, go-to-definition, find all references, rename — benefits from the same parallelism and native speed.

For developers working on large monorepos where the TypeScript language service currently takes 10+ seconds to initialize after opening a project, this changes the daily workflow. You stop planning your keystrokes around the language server’s lag. It sounds small, but it is the difference between a tool you tolerate and a tool you do not think about.

The native preview VS Code extension — “TypeScript (Native Preview)” on the marketplace — enables this today. It defers to the built-in TypeScript extension for features not yet implemented, so you get a mixed experience: fast load times and completions, with some gaps in advanced refactoring. The previews announcement makes clear that features are being added rapidly, with nightly releases.

The Verdict

The TypeScript Go compiler is the most significant infrastructure change to the TypeScript ecosystem since the language’s launch in 2012. The 10x speed claim is real for the projects that need it most — large, multi-module codebases where type-checking has become a bottleneck in CI and development workflows. For type-heavy libraries and smaller projects, the gains are more modest but still welcome.

The migration path through TypeScript 6.0 is well-designed: fix deprecations now, test side-by-side, and switch when 7.0 stabilizes. The only teams that should wait are those that depend on the programmatic API or --watch mode, which will ship in 7.1.

The most important thing you can do today is run the migration scanner against your tsconfig.json and identify the breaking changes in your codebase. That work pays off regardless of when you eventually switch — and when you do, the 10x is waiting.