TypeScript 7's Go compiler is 10x faster. Here is what actually breaks.

In March 2025, Anders Hejlsberg announced Project Corsa: a full port of the TypeScript compiler from TypeScript/JavaScript to Go. A 30-year compiler veteran choosing to rewrite one of the most widely-used language toolchains in a different language is not a small decision. The announcement got less attention than it warranted.

TypeScript 6.0 shipped in March 2026 as the last JavaScript-based release. TypeScript 7.0 will ship the Go port. The performance numbers are real. But one architectural change in the new release will affect a surprising share of production toolchains: the TypeScript Compiler API is not present in tsgo 7.0, and the blogs celebrating the speedup numbers are mostly quiet about it.

Why the compiler is being rewritten in Go

The immediate motivation was concrete. The TypeScript team was spending time explaining why their tooling felt slow on large codebases. VS Code's own source, roughly 1.5 million lines of TypeScript, took over 77 seconds for a cold type-check. That is long enough to lose context between making a change and seeing whether it compiles.

The choice of Go over Rust was deliberate and worth understanding. The type-checker is inherently parallelisable: different modules can be checked concurrently without sharing much state. Go's goroutines let the new type-checker spawn thousands of lightweight concurrent workers that share a single address space, reading symbol tables without copying data. With Rust's ownership model, that level of shared concurrent access requires Arc<Mutex<T>> wrapping, which adds both code complexity and synchronisation overhead. The team prototyped both languages; Go won on that specific workload.

What the 10x speedup actually means for your repo

The 10x figure comes from the VS Code benchmark: 77.4 seconds with the current compiler, 7.5 seconds with tsgo. That is roughly 10.3x on a 1.5 million-line codebase. For smaller repos, the gains are real but proportionally smaller.

Memory usage is halved. Language server startup (the time between opening a large TypeScript project and the editor having type information available) drops 8x. CI pipelines with multiple tsc invocations see the gains multiply: a type-check step, a test compilation, and a build compilation that each took 20 seconds now take 3 seconds each.

The speedup is largest where it hurts most: the monorepos where the current toolchain's slowness is actively costing engineering time. For a project under 50,000 lines of code, the gain is a few seconds. Still real, but not transformative for most daily workflows.

TypeScript 6.0 already changed your defaults

The Go rewrite is coming in TypeScript 7.0. But TypeScript 6.0 already landed breaking changes when it shipped in March 2026, and some teams missed them during the upgrade.

The most significant: strict mode is now on by default. In TypeScript 5.x, a tsconfig.json with no strict setting compiled in relaxed mode. From 6.0, the same configuration implies strict: true. If your codebase was deliberately running without strict mode, upgrading to 6.0 without adding "strict": false explicitly will surface new type errors.

The target option now defaults to the current-year ECMAScript specification rather than the historical ES3. If you are not setting target explicitly, you may be emitting output that does not run on older Node.js versions or specific embedded runtimes.

The ES5 target has been removed entirely. If you have "target": "ES5" in your tsconfig, TypeScript 6.0 errors on startup. The minimum supported target is ES2015. For most web projects this is irrelevant, but certain embedded or legacy server targets may care.

The Compiler API is absent in tsgo

Here is the part that will catch teams off guard.

The TypeScript Compiler API is the programmatic interface to the compiler. It lets external tools read and traverse the TypeScript AST, perform type resolution across files, and hook into the compilation pipeline. A substantial ecosystem of tooling is built on it: documentation generators, custom transformers, code generation tools, and type-inference libraries.

tsgo does not implement the Compiler API. This is not a gap that will be filled in a patch release of 7.0. It is an architectural decision: the existing API was designed around the JavaScript implementation's internal data structures, and those do not map to the Go port. A new API is planned for TypeScript 7.1, not 7.0. The 7.0 release is what most teams will first deploy, and the Compiler API simply will not be there.

Three tool categories to audit before upgrading

Tooling that depends on the Compiler API falls into three categories. The exposure varies by how directly each tool calls into the API.

Custom AST transformers and compile-time code generation

ts-patch (the fork that enables TypeScript compiler plugins), ttypescript, NestJS's custom transformer, and TypeORM's experimental decorators transformer all hook into the compilation pipeline at the AST level. They will not run on tsgo until the new API ships in 7.1.

If your build process uses ts-patch or ttypescript to run custom transformations at compile time, you will need to either stay on the tsc-based TypeScript 6.x until 7.1 ships, or migrate to a transformer approach that does not depend on the Compiler API.

Documentation generators

TypeDoc is the most widely-used TypeScript documentation generator and uses the Compiler API extensively. Generating documentation from a TypeScript source tree requires cross-file type resolution that goes beyond single-file parsing, and TypeDoc has no workaround for this in 7.0. The TypeDoc team has committed to migrating to the new API when it becomes available in 7.1, but the 7.0 gap is real.

Type inference and code generation tools

ts-morph (a high-level Compiler API wrapper), certain Prisma integration paths, OpenAPI generators that read TypeScript types to produce schemas, and any internal tooling that traverses TypeScript source programmatically all fall into this category. Whether a specific tool is affected depends on whether it calls the Compiler API directly or just invokes tsc as a subprocess.

That distinction matters. Tools that run tsc as a subprocess and parse its output are unaffected: they call the binary, not the API. Tools that import from the typescript package and call createProgram, createCompilerHost, or similar methods are affected.

How to audit your project before TypeScript 7.0 lands

# Check direct dependencies for known Compiler API consumers
grep -E '"ts-patch|ttypescript|ts-morph|typedoc|ts-transformer"' package.json

# Find files that import the typescript package programmatically
grep -r 'require("typescript")\|from "typescript"' --include="*.ts" \
  --include="*.js" --include="*.mjs" . | grep -v node_modules

# Look for Compiler API method calls in build scripts
grep -r "createProgram\|createCompilerHost\|createSourceFile" \
  scripts/ build/ tools/ --include="*.ts" --include="*.js" 2>/dev/null

The second command is the most important. If your application source imports from the typescript package at runtime, you have a Compiler API dependency. If only your build scripts do, the migration path is narrower.

Also check your webpack and bundler configuration. ts-loader with the compiler option pointing at a custom compiler host is affected. Vite uses transpile-only mode by default and does not call the Compiler API directly, so it is unaffected.

The migration for most projects

For projects without Compiler API dependencies, the migration to TypeScript 7.0 is: update the typescript package to 7.x, replace tsc with tsgo in your build scripts, and run CI to verify. The tsconfig.json format is unchanged. The JavaScript output is semantically identical: the Go compiler produces the same JavaScript output as the JavaScript compiler did. The TypeScript language itself is unchanged.

Projects with Compiler API dependencies have a few options. They can stay on the tsc-based TypeScript 6.x until 7.1 ships with the new API. They can migrate the affected tooling to alternatives that avoid the Compiler API: for documentation, generators that work from JSDoc annotations rather than compiler type resolution may be sufficient. Or they can wait for their dependencies to migrate and upgrade after those moves land.

The VS Code TypeScript extension will update automatically when 7.0 reaches stable. The editor will feel faster without any action required on your part.

TypeScript 7.0 is expected stable mid-to-late 2026. The teams that will struggle are the ones that discover a Compiler API dependency on the day they try to upgrade. The audit takes an hour. Doing it now costs almost nothing.