TypeScript 7 and Project Corsa: The Biggest Thing to Happen to TypeScript in 13 Years

I want to tell you a story about frustration first.

I was working on a large enterprise codebase last year — about 800,000 lines of TypeScript. Every time I hit save and waited for type checking to finish, I could make a cup of tea. Seriously. The compiler would grind away for 60–80 seconds, my editor would freeze, autocomplete would stop responding, and by the time everything settled down, I had completely lost my train of thought. My senior dev kept saying "just deal with it, it's the price of TypeScript." And for a long time, most of us just... accepted that.

That story is about to have a very different ending.

In early 2026, Microsoft is shipping TypeScript 7 — codenamed Project Corsa — and it is, without exaggeration, the most fundamental change to TypeScript since the language launched in 2012. They rewrote the entire compiler from scratch. In Go. And the performance numbers will make your jaw drop.

---

First — Why Does Any of This Matter?

Before we talk about TypeScript 7, it's worth stepping back and appreciating where TypeScript stands in 2026.

In August 2025, TypeScript became the #1 most-used language on GitHub, with over 2.6 million monthly active contributors — a staggering 66% growth year over year. GitHub called it "the most significant language shift in more than a decade."

Think about that. TypeScript — a language that didn't exist until 2012, a language that many developers dismissed as over-engineered and unnecessary — is now the most contributed-to language on the world's largest code platform. It powers Angular, React's type definitions, VS Code, Slack's frontend, Airbnb's codebase, and thousands of other production applications. It's not a trend anymore. It's the default.

Which makes the performance problem more urgent, not less. The bigger your codebase grows, the worse the build times get. And codebases have been growing.

---

So What Is Project Corsa, Exactly?

Microsoft announced Project Corsa in March 2025 — a complete, ground-up rewrite of the TypeScript compiler and language service in Go (Google's programming language). The existing TypeScript compiler — called "Strada" internally — is written in TypeScript itself and runs on Node.js. That's elegant, but it comes with a ceiling on performance.

The new Go-based compiler is called tsgo, and it runs as a standalone native binary. No Node.js required. It takes full advantage of Go's parallel processing, shared memory threading, and native execution speed. And the results in real-world codebases are extraordinary.

Here are actual benchmarks from Microsoft's own December 2025 testing on major real-world projects:

Project	Old Compiler (tsc)	New Compiler (tsgo)	Speedup
VS Code (~1.5M lines)	77.8 seconds	7.5 seconds	~10x faster
Playwright	11.1 seconds	1.1 seconds	~10x faster
Sentry	133.08 seconds	16.25 seconds	~8x faster
TypeORM	~13 seconds	~1 second	~13x faster

Let that sink in. The VS Code codebase — one of the most complex TypeScript projects in the world — went from 77 seconds to 7.5 seconds. Sentry went from 2 minutes 13 seconds to 16 seconds. One developer on Reddit reported their type-checking time dropped by 75% on their company's codebase.

These are not cherry-picked toy examples. These are the actual codebases used to build the tools that millions of developers use every day.

And it's not just build times. The language service — the part that powers your editor's autocomplete, go-to-definition, error highlights, and refactoring tools — is also rewritten. Editor startup time dropped from around 10 seconds to roughly 1.2 seconds on the VS Code codebase. That's an 8x improvement in how quickly your editor is ready to help you. Memory usage is also approximately half of the current implementation.

---

Why Go? (Everyone Had Opinions About This)

When Microsoft announced the rewrite, the internet had very loud opinions. The most common reaction was: "Why Go? Why not Rust?"

It's a fair question — Rust is the darling of high-performance systems programming right now, and tools like esbuild and Biome have shown what Rust can do for JavaScript tooling. But the TypeScript team had solid reasons for choosing Go:

• Structural similarity — TypeScript's codebase uses patterns that translate more naturally to Go than Rust. The port is essentially a near-direct translation of existing TypeScript compiler logic, which reduces bugs and maintains behavior parity.
• Shared memory parallelism — Go's goroutines allow the compiler to build multiple projects in parallel using shared memory, which is exactly what monorepos need. This is harder to do cleanly in Rust.
• Go's garbage collector matches compiler memory patterns well, freeing the team from manual memory management headaches that would complicate a Rust port.
• The team knows Go — an underrated but very real reason to choose any technology. A language the team understands deeply is better than a theoretically superior language they'd be learning on a project this critical.

The naming gives you a clue into how Microsoft thinks about this shift. The original TypeScript compiler is codenamed Strada (Italian for "road" or "path") — the journey so far. The new one is Corsa (Italian for "race" or "run") — the performance-focused leap forward. Microsoft loves a theme.

---

Does This Change How I Write TypeScript?

This is the most important question, and the honest answer is: almost nothing about your day-to-day TypeScript changes.

Your interface definitions, generics, utility types, enums, decorators (in supported targets), async/await — all of it works exactly the same. The TypeScript language specification is not changing. Microsoft has been very clear about this. You write TypeScript exactly as you do today. The compiler is the thing that's changing, not the language.

// This still works exactly as before in TypeScript 7
interface User {
  id: number;
  name: string;
  email: string;
}

async function getUser(id: number): Promise<User> {
  const response = await fetch(`/api/users/${id}`);
  return response.json() as User;
}

// Generic utilities — unchanged
type ReadonlyUser = Readonly<User>;
type PartialUser = Partial<User>;
  

What does change in TypeScript 7 are some breaking changes worth knowing about:

• Strict mode is ON by default — TypeScript 7 enables strict: true automatically. If your existing project runs without strict mode, you'll see new errors after upgrading. This is actually a good thing long-term — strict mode catches real bugs — but it requires a migration pass.
• ES5 target is dropped — TypeScript 7 no longer supports compiling down to ES5. Minimum target is ES2021. If you're still targeting IE11 (and if you are, I'm truly sorry for your situation), you'll need to stay on TypeScript 6.
• AMD / UMD / SystemJS module formats removed — Legacy module systems that very few people still use. If you're on CommonJS or ESM, you're fine.
• Classic Node module resolution removed — You'll need moduleResolution: "bundler" or "node16".
• Some JSDoc tags dropped — @enum and @constructor are no longer recognized. Pure JavaScript projects using JSDoc for typing may see new errors.

---

The TypeScript 5.8 and 5.9 Story — What Happened Before TypeScript 7

Now you might wonder — if the team was spending all their energy on TypeScript 7, what happened to the regular TypeScript releases? TypeScript 5.8 shipped in March 2025, and this is why it had relatively fewer headline language features compared to earlier versions. The team was quietly pouring most of their effort into Project Corsa.

That said, TypeScript 5.8 had genuinely useful improvements:

• Smarter conditional return type inference — TypeScript 5.8 can now detect subtle type errors in functions with conditional return types that previous versions silently missed. Real bugs were going undetected before.
• Run TypeScript directly in Node.js — With Node.js 23.6+ and the new --erasableSyntaxOnly flag, you can run .ts files directly without a compile step. TypeScript annotations are simply stripped at runtime. No tsc, no ts-node, no build step for development scripts.
• require() support for ESM modules — With --module nodenext, TypeScript finally properly supports require() for JavaScript modules, removing a long-standing pain point in mixed CommonJS/ESM codebases.

TypeScript 5.9 (released in mid-2025) continued polishing. And then TypeScript 6.0 will serve as a "bridge" — the last JavaScript-based TypeScript release, aligned closely with TypeScript 7's behavior so migrations are as smooth as possible.

---

How to Try TypeScript 7 Today

The native preview is available right now. You can try it alongside your existing TypeScript setup:

# Install the native preview compiler
npm install -D @typescript/native-preview

# Run the new compiler (works like tsc)
npx tsgo --version

# Type-check your project
npx tsgo --noEmit

# You can also run both side by side
npx tsc --noEmit   # Original compiler
npx tsgo --noEmit  # New Go-based compiler
  

The type-checking results are virtually identical. Out of ~20,000 compiler test cases, TypeScript 7 matches the old compiler in all but 74 — and those 74 are mostly known intentional changes. Many teams are already using tsgo for type-checking in CI while keeping the old tsc for JavaScript emit (which is still being finalized in the native port).

You can also try it in VS Code today by installing the TypeScript Nightly extension and enabling the native language service in your settings. The editor responsiveness improvement is immediately noticeable, especially on larger projects.

---

What About My Tools — ESLint, Prettier, Webpack?

This is the most important practical concern right now. Here's the honest picture:

Many popular tools depend on the TypeScript Compiler API — called the Strada API — for things like accessing the AST, running transforms, and integrating with the type checker. TypeScript 7's new Corsa API is a complete replacement that is still a work in progress.

What this means for you:

• ESLint / typescript-eslint — Will need to update for Corsa API compatibility. Maintainers are tracking this. Until then, run ESLint using the old TypeScript package and use tsgo for type-checking separately.
• Prettier — Not affected. Prettier does its own parsing and doesn't depend on the TypeScript compiler API.
• Vite / esbuild / SWC — Also not affected. These tools strip types without using the full TypeScript Compiler API.
• Custom webpack transforms, ts-jest, some Babel plugins — These may need updates. Check your specific tools against the TypeScript 7 compatibility tracker on the TypeScript GitHub repo.

Microsoft's recommended workaround during the transition: install both typescript (version 6.x) and @typescript/native-preview side by side. Use the 6.x API for tools that need it, and use tsgo for the fast type-checking and editor experience.

---

Node.js Now Runs TypeScript Natively — No Build Step

Separate from TypeScript 7 but equally exciting: as of Node.js 22.18.0 (released July 2025), Node.js natively supports running TypeScript files — no build step, no configuration, no ts-node required.

// Save this as server.ts
const message: string = "Hello from TypeScript, no build step!";
console.log(message);

// Run it directly
node server.ts  // Works on Node.js 22.18.0+
  

Node strips the TypeScript type annotations at runtime using a technique called "type erasure" — it treats types as comments, essentially. It's not a full TypeScript compiler; it won't catch type errors at runtime. But for scripts, simple tools, and development workflows where you just want to run TypeScript without a build step, this is genuinely life-changing.

Since 2009, running anything before JavaScript in Node.js meant adding a tool to your stack — CoffeeScript, Babel, ts-node. Each tool adds complexity and potential failure points. Now, for erasable TypeScript, you just... run the file. That's it.

---

How to Migrate — A Practical Plan

If you're thinking about getting your project ready for TypeScript 7, here's a sensible approach:

1. Step 1 — Enable strict mode now on TypeScript 5.x. Run it, fix the errors. Getting ahead of the strict-by-default change in TypeScript 7 is the most valuable thing you can do today. It will also find real bugs in your existing code.

   // tsconfig.json
   {
     "compilerOptions": {
       "strict": true  // Add this now — don't wait for TypeScript 7
     }
   }
         

2. Step 2 — Upgrade your module resolution. Switch from moduleResolution: "node" to "node16" or "bundler". Microsoft provides a migration script: npx @andrewbranch/ts5to6 --fixBaseUrl your-tsconfig.json
3. Step 3 — Drop ES5 targets. Update your tsconfig.json target to at minimum "ES2021".
4. Step 4 — Install @typescript/native-preview and run tsgo --noEmit on your project. See what new errors appear. Fix them before TypeScript 7 is mandatory.
5. Step 5 — Audit your JSDoc if you have any JavaScript files using JSDoc type annotations. The @enum and @constructor tags are no longer supported.

---

The Bigger Picture: What This Unlocks for the Future

Microsoft's Daniel Rosenwasser mentioned something in the TypeScript 7 announcement that's easy to skip over but is actually really exciting: the TypeScript team said the native port unlocks language features that were "once considered out of reach" due to the performance constraints of the old compiler.

Think about that. There are TypeScript features the team wanted to build but couldn't because they would have made the slow compiler even slower. A 10x faster compiler means 10x more headroom for the type system to do more sophisticated analysis, deeper inference, and smarter checks — all without making your editor freeze.

The team is also finally moving to LSP (Language Server Protocol) — a standard that will make TypeScript's language service work properly with every editor, not just VS Code. Vim, Emacs, Helix, Zed — all editors that speak LSP will get first-class TypeScript support. This is something developers have been asking for for years.

There's also the CI/CD angle. If your TypeScript build in CI takes 5 minutes today, it could take 30 seconds after TypeScript 7. Multiply that across every PR, every developer, every day — the compounded productivity and infrastructure cost savings at scale are enormous.

---

Final Thoughts — This Is a Big Deal

I've been writing about TypeScript since version 2.x. I've seen it go from "weird Microsoft experiment" to "the way serious JavaScript is written." And in all that time, the core toolchain — the compiler, the language service — has been more or less the same architecture, just gradually improved.

TypeScript 7 is the first time since the language launched in 2012 that the foundation itself is being rebuilt from the ground up. Not because it was broken — TypeScript's type system is excellent — but because the team realized that the performance ceiling of the old architecture was holding the whole ecosystem back.

The fact that they rewrote a 1.5-million-line compiler in a different language, maintained near-perfect type-checking parity, and got it to a stable-enough state for daily use within about 9 months of announcing the project — that's genuinely impressive engineering.

Remember that slow build time I told you about at the start? 77 seconds for the VS Code codebase. With TypeScript 7, it's 7.5 seconds. My 60-second tea break just became a quick sip.

Try the native preview on your project. Enable strict mode today. Start your migration now so you're not scrambling when TypeScript 7 becomes the standard. The era of slow TypeScript builds is ending — and it's about time.

Have you already tried tsgo on a real project? What kind of speedup did you see? Drop it in the comments — I'd love to compare notes. 👇

Keep shipping. Keep learning. 🚀

---

Tags: TypeScript, TypeScript 7, Project Corsa, tsgo, Microsoft, JavaScript, Web Development, Frontend, Node.js, Developer Tools, 2026