TypeScript 7.0 Project Corsa: Why a Compiler Rewritten in Go Delivers 10x Faster Builds

Have you ever grabbed a cup of coffee while waiting for tsc --noEmit to finish? When a single type check on a large monorepo takes over a minute, the temptation to just use any is real. Microsoft has addressed that frustration in a pretty fundamental way — by completely rewriting the entire TypeScript compiler from JavaScript into Go.

Announced in March 2025 by TypeScript creator Anders Hejlsberg himself, this project's internal codename is "Corsa." The timeline is a bit unusual since two versions were developed in parallel: TypeScript 7.0 beta shipped in January 2026, while TypeScript 6.0 — the final version of the JS-based compiler — was released in March of the same year. The key point is this: not a single line of TypeScript syntax changed, yet build speed improved roughly 10x purely by swapping out the compiler's internal implementation.

In this article, we'll look at exactly what Project Corsa changed, whether you can try it right now, and what pitfalls to be aware of before adopting it in production — with real benchmark data.

Core Concepts

The Entire Compiler Was Replaced, but the Syntax Stayed the Same?

When I first heard the news, I briefly wondered "Do I need to write Go code now?" — but not at all. What changed is the tooling that processes .ts files; the TypeScript code developers write is 100% identical.

Here's specifically what was replaced with Go:

"Why Go?" Microsoft evaluated several languages, including Rust and C#. Go was ultimately chosen for its lightweight goroutine-based concurrency model, built-in GC (reducing memory management burden), and language characteristics that made porting the existing JS codebase more tractable. The full discussion is available at Why Go? — microsoft/typescript-go Discussion #411.

Where Does the "10x" Number Come From?

The official announcement highlights roughly 10x improvement as the headline figure. This results from the native execution speed gained by switching languages, combined with Go's goroutine-based parallel processing.

Goroutines might sound unfamiliar, so here's a simple explanation. JavaScript is single-threaded, so type checking must process files sequentially. Go can spin up thousands of goroutines — lightweight concurrency units — to analyze multiple files in parallel simultaneously. This means modern multi-core CPUs can finally be fully utilized.

Breaking down the measurements makes this more concrete. Based on the VS Code source (approximately 1.5 million lines), the official announcement reports that Language Server initial load time dropped from 9.6 seconds to 1.2 seconds, and full type check time dropped from approximately 77 seconds to approximately 7.5 seconds. The former is the responsiveness you feel when opening a project in an editor; the latter is the time for a full check run in CI or on the command line. The two numbers differ because they measure different things.

Memory usage also dropped by 3–4x, which directly affects CI costs. If you've been forced to use larger instances because of type checking memory demands, this can represent meaningful savings.

Version Strategy: 6.x as a 'Bridge Release'

Version numbers can be confusing here, so let me clarify. The timeline is a bit unusual because two versions were developed simultaneously:

• TypeScript 7.0 Beta: Released January 2026 — first public version of the Go-based compiler
• TypeScript 6.0 Stable: Released March 2026 — the final version of the JS-based compiler

6.0 serves as a bridge to ease migration to 7.0. It cleans up deprecated options and absorbs breaking changes, providing a stepping stone for a safe transition to 7.0. That's why migrating through 6.0 first is recommended before moving to 7.0.

It's also worth noting the major default value changes in 6.0:

// Key tsconfig.json default value changes as of TypeScript 6.0
{
  "compilerOptions": {
    "strict": true,       // Now defaults to true (previously false)
    "module": "esnext",   // Default changed
    "target": "es2025",   // Default changed
    "types": []           // Default changed to empty array
  }
}

strict: true becoming the default is welcome for new projects, but when migrating existing projects it can unleash unexpected type errors — worth preparing for in advance.

Practical Application

Example 1: Installing the Preview and Measuring the Speed Difference Yourself

You can experience the speed difference on an existing project right now. By installing @typescript/native-preview side-by-side, you can experiment without touching your existing tsc.

# Install the preview package (same command works with pnpm/yarn)
npm install --save-dev @typescript/native-preview
 
# Check version
npx tsgo --version
 
# Run type check (without emit)
npx tsgo --noEmit

I ran this on a mid-size project (approximately 30k lines) and it felt roughly 3–4x faster. The official benchmark numbers show the effect grows larger with bigger projects.

Below are the major project benchmarks included in the official announcement (A 10x Faster TypeScript):

Example 2: Applying a Parallel Strategy to Your CI/CD Pipeline

The recommended approach during the preview stage is to keep both tsgo and the existing typescript around together. Since feature completeness isn't 100% yet, existing tsc can catch errors that tsgo misses.

// package.json
{
  "scripts": {
    "typecheck": "tsgo --noEmit",        // New native compiler (fast)
    "typecheck:legacy": "tsc --noEmit",  // Fallback legacy compiler
    "typecheck:ci": "tsgo --noEmit && tsc --noEmit" // Run both in CI (stops immediately on first failure)
  },
  "devDependencies": {
    "typescript": "^6.0.0",
    "@typescript/native-preview": "latest"
  }
}

In CI, you can split the two checks into separate steps to review each result independently:

# GitHub Actions example — separate steps let you see each result as its own report
- name: Type check (native)
  run: npx tsgo --noEmit
 
- name: Type check (legacy fallback)
  run: npx tsc --noEmit

The idea is to get fast feedback from tsgo during local development, while running both in CI to maintain a safety net. Note that typecheck:ci in package.json uses && and stops immediately on the first failure, whereas the separate-steps approach in GitHub Actions lets you see both results independently. Choose whichever fits your workflow. Once things stabilize, simply remove typecheck:legacy.

Example 3: IDE Integration Setup

If you're on VS Code, install the "TypeScript (Native Preview)" extension from the Marketplace. Once installed, the native language server activates automatically — no extra configuration needed to start feeling the difference. JetBrains WebStorm officially supports the tsgo language server starting from version 2025.2.

A Language Server is a background process that provides IDEs with autocomplete, type error display, and code navigation features. tsgo reimplements this language server role in Go as well, so autocomplete response speed in your editor also noticeably improves.

Pros and Cons

Personally, my biggest concern was Compiler API compatibility — which I resolved for now by running the old tsc in parallel. But if you're using tools like ESLint plugins or ts-morph, it's worth knowing that full stabilization will take more time.

Advantages

Disadvantages and Caveats

Honestly, there are quite a few downsides too. In particular, projects using legacy targets may face higher migration costs than expected.

The Compiler API (Strada API) is the programmatic interface TypeScript exposes to external tools. ESLint's TypeScript plugin, code transformation tools like ts-morph, and many IDE extensions use this API to access TypeScript's internals. Corsa is designing a new API, and it is not compatible with the existing Compiler API until it stabilizes.

The Most Common Mistakes in Practice

1. Assuming tsgo replaces emit too — In the current preview stage, tsgo is recommended primarily for type checking (--noEmit). Keeping your existing pipeline for bundling and transpilation is the safer approach.
2. Trying to jump straight to 7.0 without migrating through 6.0 — Getting to TypeScript 7.0 requires going through 6.0 first. Run the ts5to6 tool beforehand to handle things like removing baseUrl and adjusting rootDir.
3. Removing legacy tsc from CI immediately after switching to tsgo — Tools dependent on the plugin API aren't fully compatible yet, so running both in parallel until stability is confirmed is the safer path.

Closing Thoughts

TypeScript 7.0 / Project Corsa is a case study in fundamentally improving the developer experience by changing the tooling rather than the language. The fact that build speed can be 10x faster without changing a single line of code is a meaningful shift, especially for teams operating large codebases.

Here are the steps you can take to get started right now:

1. You can install the preview package side-by-side and experience the speed difference firsthand. Run npm install --save-dev @typescript/native-preview and then npx tsgo --noEmit on your existing project to compare.
2. It's recommended to add a "typecheck": "tsgo --noEmit" script to your package.json and keep the existing tsc --noEmit as typecheck:legacy in parallel. This lets you experiment while maintaining a safety net.
3. If you're using VS Code, try installing the "TypeScript (Native Preview)" extension. You'll immediately notice faster autocomplete responses and error display in the editor.
4. For seniors and tech leads evaluating team adoption, running benchmarks against your actual codebase and writing up a report is a great approach. Compare tsgo --noEmit and tsc --noEmit execution times and share the results with your team.

References

• A 10x Faster TypeScript | Microsoft TypeScript Blog
• Announcing TypeScript Native Previews | Microsoft TypeScript Blog
• Progress on TypeScript 7 - December 2025 | Microsoft TypeScript Blog
• Announcing TypeScript 7.0 Beta | Microsoft TypeScript Blog
• Announcing TypeScript 6.0 | Microsoft TypeScript Blog
• microsoft/typescript-go | GitHub
• TypeScript (Native Preview) VS Code Extension | VS Code Marketplace
• Why Go? — microsoft/typescript-go Discussion #411 | GitHub
• TypeScript Migrates to Go: What's Really Behind That 10x Performance Claim? | Architecture Weekly
• tsgo Released! TypeScript 7's New Compiler Installation Guide | DEV Community
• TypeScript 7.0 will be 10x faster with Go | Appwrite Blog