TypeScript 7.0: Why a Pragmatic Go Port Beat the Rust Hype

Waiting for type-checking is a tax that every large-scale JavaScript developer pays daily. Whether it is local watch-mode lag or a bottlenecked CI pipeline, the TypeScript compiler has long struggled under the weight of its own success.

TypeScript 7.0, which arrived as a Release Candidate on June 18, 2026, aims to eliminate this tax. It is not a minor iteration with a few new utility types. Instead, Microsoft has shipped a complete port of the compiler and language service written in Go. Codenamed Project Corsa, this native port replaces the legacy JavaScript-based compiler, Strada, and delivers build times that are roughly 10 times faster.

But the real story of TypeScript 7.0 is not just the speed. It is the pragmatic engineering decision to choose Go over Rust, a choice that allowed Microsoft to ship a highly compatible compiler in a fraction of the time a ground-up rewrite would have taken. For developers, this release offers massive performance gains, but it also introduces a temporary tooling fragmentation and strict configuration requirements that require a deliberate migration strategy.

The Pragmatic Port: Why Go Beat Rust

When toolmakers rewrite JavaScript infrastructure for speed, the default choice in recent years has been Rust. Tools like SWC, Rolldown, and Biome have established Rust as the industry standard for high-performance frontend tooling. Yet, the TypeScript team chose Go.

The decision came down to the difference between a port and a rewrite. A Rust rewrite of a compiler as complex as TypeScript would have required a ground-up architectural redesign. Rust's strict borrow checker does not map cleanly to the deeply nested, graph-like structures and mutable state common in compiler type-checkers. Such an effort would have taken years and introduced a high risk of semantic drift.

Go, by contrast, features a garbage collector, straightforward memory layout, and a concurrency model that aligned well with the existing TypeScript compiler structure. This allowed the team to execute a faithful, file-by-file translation of the codebase. By preserving the exact logic and semantics of the original compiler, Microsoft ensured that TypeScript 7.0 remains highly compatible with existing codebases while unlocking native execution speeds and shared-memory multithreading.

Performance Reality Check

The performance gains of this Go-native engine are stark. On large, real-world codebases, full build times have dropped by 8x to 12x.

xychart-beta
    title "TypeScript 7.0 Build Speedup Factor"
    x-axis [vscode, sentry, bluesky, playwright, tldraw]
    y-axis "Speedup (x-fold)" 0 --> 13
    bar [11.9, 8.9, 8.7, 8.7, 7.7]

According to Microsoft's benchmarks, type-checking the VS Code codebase (roughly 1.5 million lines of code) dropped from 125.7 seconds under TypeScript 6.0 to just 10.6 seconds under TypeScript 7.0. Sentry saw its build times fall from 139.8 seconds to 15.7 seconds.

Crucially, this speed does not come at the cost of system resources. TypeScript 7.0 actually reduces aggregate memory consumption during builds. For example, the VS Code build saw an 18% reduction in memory usage, dropping from 5.2GB to 4.2GB, while Bluesky saw a 26% drop from 1.8GB to 1.3GB.

In-editor responsiveness sees an even greater impact. Previously, opening a file with an error in the VS Code codebase took 17.5 seconds for the editor to display the first red squiggle. Under TypeScript 7.0, that feedback loop is cut to under 1.3 seconds, a 13x speedup that fundamentally changes the feel of local development.

The Developer Angle: Parallelism, Coexistence, and the API Gap

To adopt TypeScript 7.0 today, you can install the Release Candidate via npm:

npm install -D typescript@rc

This replaces your standard tsc executable with the Go-native binary. The native compiler exposes new flags designed to exploit modern multi-core processors:

• --checkers N: Controls the number of parallel type-checking workers (defaults to 4). Large monorepos on beefy development machines can scale this up, while resource-constrained CI runners should tune it down.
• --builders N: Enables parallel compilation of project references, a major win for monorepos.
• --singleThreaded: Disables parallelism entirely, which is useful for debugging or isolating performance benchmarks.

However, there is a major catch that will delay adoption for many teams: the programmatic API gap.

TypeScript 7.0 does not ship with a stable programmatic API. That API is slated for TypeScript 7.1, which is at least several months away. This means that any tool relying on TypeScript's compiler internals, such as typescript-eslint, ts-morph, or custom AST transformers, cannot run on TypeScript 7.0 natively yet.

To work around this without missing out on fast type-checking in CI, you can run TypeScript 6.0 and 7.0 side-by-side. By using the compatibility package @typescript/typescript6, you can alias your existing tooling to the older compiler while using the new Go-native compiler for standard type-checks.

Your package.json configuration would look like this:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "@typescript/native-preview": "^7.0.0-rc"
  }
}

This configuration keeps your ESLint and testing frameworks happy on the 6.0 bridge, while allowing you to run the Go-native compiler via npx tsgo (or tsc if you install the RC directly) for rapid local and CI type-checking.

Breaking the Legacy: Configuration and JSDoc Purge

If your codebase has not been updated recently, migrating to TypeScript 7.0 will require some configuration cleanup. The new compiler hard-adopts several strict defaults that were previously optional in TypeScript 6.0, and it completely removes several legacy options.

Several key compiler options are now enabled by default with no opt-out mechanism:

• strict is permanently set to true.
• module defaults to esnext.
• noUncheckedSideEffectImports is enabled by default.
• types now defaults to an empty array ([]). This means implicit globals from your node_modules/@types folder, such as @types/node, will no longer be resolved automatically. You must list them explicitly in your tsconfig.json:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Additionally, if your tsconfig.json sits outside your src/ directory, you must now explicitly define rootDir and include paths to prevent compilation errors:

{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

Several legacy options have been completely removed from the compiler. If your configuration relies on target: es5, moduleResolution: node (or node10), module: amd (or umd, systemjs), baseUrl, or downlevelIteration, the compiler will reject your configuration. You must modernize these options, switching to nodenext or bundler for module resolution, and using relative paths instead of baseUrl.

JavaScript codebases relying on TypeScript for JSDoc type-checking also face breaking changes. TypeScript 7.0 rewrites how .js files are analyzed, moving away from Closure-style JSDoc. The @enum tag is no longer supported (use @typedef instead), @class on a function no longer marks it as a constructor, and you can no longer use runtime values where types are expected without using the typeof operator.

The Verdict

TypeScript 7.0 is a highly successful exercise in pragmatic software engineering. By resisting the urge to rewrite the compiler from scratch in Rust, the team delivered a stable, production-ready compiler that is an order of magnitude faster, while maintaining strict semantic parity with the codebase developers already trust.

For teams with large codebases, the productivity gains of sub-second editor diagnostics and ten-second CI builds are too large to ignore. While the programmatic API gap in 7.0 requires a temporary dual-compiler setup for linting, the performance leap makes that minor architectural complexity well worth the effort.