Back to BlogTypeScript

TypeScript 7.0: Go Compiler, 10x Faster Builds, and Everything That Just Broke

TypeScript 7.0 shipped a Go-native rewrite of the compiler (Project Corsa) on July 8, 2026. The VS Code codebase went from 78 seconds to 7.5 seconds. But the Compiler API is gone in 7.0, ES5 target is removed, and Vue/Svelte/Astro support is not there yet. Here is what actually changed and how to upgrade without blowing up your build.

TypeScriptGocompilerperformancemonorepotooling
TypeScript 7.0: Go Compiler, 10x Faster Builds, and Everything That Just Broke

TypeScript 7.0: Go Compiler, 10x Faster Builds, and Everything That Just Broke

TypeScript 7.0 landed on July 8, and it is the biggest change to the TypeScript toolchain since TypeScript itself existed. The headline: a ground-up rewrite of the compiler in Go, codenamed Project Corsa. The numbers are real — Microsoft's own VS Code codebase dropped from 78 seconds to 7.5 seconds. Sentry went from 133 seconds to 16.

That is not a minor improvement. That is the difference between "go get coffee" and "just wait a tick."

What Actually Got Faster (and Why)

The 10x figure is the sum of two separate wins. Native compilation from Go rather than JavaScript gets you roughly 3-4x. The rest comes from parallelism that was simply not achievable with the old V8-bound single-threaded model. TypeScript can now type-check and emit multiple files simultaneously, saturating all your CPU cores instead of one.

The key enabler for parallel .d.ts emit is isolatedDeclarations. If you are running a monorepo, enabling "isolatedDeclarations": true alongside "declaration": true is the first thing you do after upgrading. It lets TypeScript emit declaration files for each module without waiting on the whole-program type check, unlocking 3x–15x faster builds on large repos.

The most common error you will hit after enabling it:

Function must have an explicit return type annotation with --isolatedDeclarations

That means exported functions without explicit return types. TypeScript needs to know the shape without running the full checker. Fix it:

// before
export function getUser(id: string) {
  return db.users.findOne(id);
}

// after
export function getUser(id: string): Promise<User | null> {
  return db.users.findOne(id);
}

It is tedious in the short term. In exchange you get a type contract that is explicit at every public boundary, which is better design anyway.

What Broke

Several things. I will be direct.

**--target es5 is gone.** The minimum supported output target is now ES2015. If you are still shipping ES5 for legacy browser support in 2026, you need a separate transpiler step — Babel, or whatever your bundler provides. This is the right call. TypeScript should not be a polyfill machine.

**module: "amd", "umd", "systemjs", and "none" are removed.** Supported output formats are now ESNext, ES2022, NodeNext, and CommonJS. If your tsconfig.json still says "module": "umd", fix it before upgrading.

**--baseUrl and --moduleResolution node10 are gone.** If you are using baseUrl for path aliases instead of proper paths or package.json exports, now is the time to clean that up. moduleResolution: "bundler" or "nodenext" is what you want.

**--strict is now the default.** This one surfaces in projects that have been quietly skipping strict mode. You might see a flood of null-check errors the first time you run tsgo on an existing codebase. Budget the time to fix them — they are real bugs, not noise.

The Compiler API Is Missing in Action

Here is the sharp edge that will hurt tooling-heavy projects: **tsgo does not expose the TypeScript Compiler API.** The new API, codenamed Strada, is planned for TypeScript 7.1, not 7.0. In practice this means:

  • **ts-morph** — broken

  • **tsup with --dts** — broken

  • **ts-jest** — broken

  • Anything calling ts.createProgram() or walking the AST programmatically — broken

If your build pipeline relies on any of these, you cannot upgrade yet. Wait for 7.1 or track the respective repos. This is not a corner case — it affects a large chunk of real-world TypeScript setups.

What Frameworks Are Supported

Standard .ts and .tsx files: yes. Everything else: not yet.

Vue, Astro, Svelte, MDX, and Angular template checking are **not supported in TypeScript 7.0**. These all rely on custom language plugins or transform pipelines that hook into the compiler API — which does not exist in tsgo yet. Your .vue and .svelte files will not see speed improvements until those ecosystems catch up with 7.1 and beyond.

The Migration Path Is TS 6 First

The most common mistake people are making right now: jumping directly from TypeScript 5.x to 7.0. Do not do this.

TypeScript 6 was explicitly designed as a staging ground. It flags every breaking change that 7.0 removes — with deprecation warnings, not explosions. Running TS 6 first means by the time you upgrade to 7, you have already eliminated the things that would otherwise silently detonate. Skipping this step is why people are posting "my build exploded" threads this week.

Once you are on TS 7, enable isolatedDeclarations for any project emitting declaration files. The annotation work is front-loaded; the build speed payoff runs on every subsequent CI run.

Should You Upgrade Today?

If you are running a plain TypeScript codebase without compiler plugins, tsup --dts, ts-jest, or Vue/Svelte/Astro transforms: **yes, upgrade now.** The build speed improvement is not incremental — it is a step change you will feel every time you push.

If your project uses the Compiler API or non-TS file transforms: **wait for 7.1.** The Strada API is actively being built and the ecosystem is moving fast.

Either way: go through TS 6 first.