TypeScript 7: What the 10x Speedup Actually Means for Your Codebase

# TypeScript 7: What the 10x Speedup Actually Means for Your Codebase

TL;DR: Microsoft shipped TypeScript 7 — a ground-up rewrite of the compiler in Go. Builds are 8–12x faster, editor feedback is 13x faster, and language server crashes dropped 60%. No API yet (that's 7.1), but you can run it side-by-side with TS 6 today. Here's what actually changes for your team.

---

The Numbers That Matter

Let's skip the marketing and go straight to the benchmarks. The TypeScript team published build times on real open-source codebases:

Memory improved too — VS Code's build uses 18% less RAM, Bluesky's uses 26% less.

But here's the stat that matters most for daily work: opening a file with an error in the VS Code codebase went from 17.5 seconds to 1.3 seconds. That's the difference between an editor that gets out of your way and one that makes you check your phone while it thinks.

Real-World Impact

The announcement blog packed testimonials from companies that ran TS 7 previews:

Slack: TypeScript 7 eliminated 40% of their merge queue time. CI type-checking dropped from 7.5 minutes to 1.25 minutes. Local editor performance went from "unusable" — engineers would let CI handle type-checking because the language server couldn't load the codebase — to loading in a few seconds. Canva: First error in-editor went from 58 seconds to 4.8 seconds. That's the difference between catching a bug while you're still typing and finding out about it after your coffee break. Microsoft News Services: 400 hours saved per month on CI builds. Not per year — per month. PowerBI: Called TS 7 in the editor "life-saving." Adopted it as default before rename functionality even shipped in VS Code. Vanta: 9x faster builds on their largest project.

Why Go?

The choice of Go isn't about Go-vs-Rust drama. It's pragmatic.

TypeScript's original codebase (written in TypeScript/JavaScript) is single-threaded and garbage-collected by V8. That's fine for an editor plugin. It's not fine for builds that touch hundreds of thousands of files.

Go gives the TypeScript team three things they couldn't get from a JS runtime:

1. Native code speed. No JIT warmup, no V8 optimization tiers — compiled Go runs at full speed from the first invocation.

1. Shared-memory multithreading. Go's goroutine model maps cleanly to the problem: parsing is embarrassingly parallel across files, type-checking can be partitioned, and emit can run concurrently. The JS event loop model was never designed for this.

1. Control over memory layout. The team mentioned that Go's value types and stack allocation let them avoid the pointer-chasing that dominates V8 heap objects. When your compiler traverses ASTs millions of times per build, cache locality matters.

The rewrite is structurally faithful — the team deliberately mirrored the original codebase's architecture. The logic is the same. The execution is what changed.

What Gets Faster

Pretty much everything. But some things matter more than others:

Builds (tsc)

The headline numbers. 8–12x on full builds, but incremental builds (--watch mode) benefit even more because TypeScript 7's startup time is a fraction of TS 6's. When you save a file and wait for the re-check, that tight loop is where the speedup feels transformative.

Editor Feedback

This is the one you'll notice first. Diagnostics (red squiggles), auto-completion, find-all-references, go-to-definition — all of these hit the language server. With TS 7, the language server operates on all cores and returns results while you're still typing.

The team reported an 80% reduction in failing language server commands and a 60% reduction in server crashes. Crashes aren't just annoying — they silently kill diagnostics until you notice and reload the window. Fewer crashes means less "why aren't my errors showing up?" debugging.

CI Pipelines

Slack's 7.5 minutes → 1.25 minutes for type-checking might be the most impactful number in the announcement. CI type-checking is a gate. Shrinking it from "go get coffee" to "take a sip of coffee" changes how teams structure their pipelines. You can afford to type-check on every push without optimizations like caching or skipping.

The Big Caveat: No API (Yet)

TypeScript 7.0 ships with tsc and the language server, but no programmatic API. That's a deliberate choice — the team wanted to ship the compiler and editor experience first, and the API in 7.1.

This matters because a lot of tooling consumes TypeScript as a library:

• typescript-eslint — parses TypeScript to run ESLint rules on typed ASTs
• ts-morph — programmatic code modification
• ts-node / tsx — runtime TypeScript execution
• Custom codemods and linters — anything that imports from typescript

If your toolchain depends on these, you have two options:

Option A: Side-by-side with TS 6. Install TypeScript 7 alongside @typescript/typescript6, which provides tsc6 and the TS 6 API:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

This gives you tsc (v7) for builds and typescript (v6 API) for tooling. typescript-eslint continues to work because it resolves the typescript package and gets TS 6's API.

Option B: Wait for 7.1. If you're not blocked by build times, staying on TS 6 until the API ships is completely valid. The team explicitly supports this path.

Once 7.1 lands with the new API, tooling authors will need to update their integrations. The new API will be different from the TS 6 API — not just a drop-in replacement. Expect a transition period where tooling works with both.

Parallelization Controls

TypeScript 7 introduces flags to tune how work gets distributed:

• --checkers N — control type-checker parallelism (experimental)
• --builders N — control project reference builder parallelism (experimental)
• --singleThreaded — disable parallelism entirely (useful for debugging or constrained CI environments)

Most teams won't need these. The defaults scale well. But if you're on a 64-core CI runner and wondering why you're not seeing full utilization, these are the knobs.

CI Number Differences to Watch For

The team explicitly warns that type-checking results may differ between TS 6 and TS 7 when parallelized. The same checks run — but the order they run in can change, which means a file that was previously checked after its dependency was fully resolved might now be checked concurrently. Most codebases won't notice. If you have code that depends on declaration emit ordering, audit it.

The test suite is massive — tens of thousands of tests built over a decade, running on every commit. But if you have a particularly gnarly monorepo with circular references and declaration files that depend on specific emit ordering, run a comparison build before switching CI.

Migration in Practice

# 1. Install TS 7
npm install -D typescript@latest

# 2. Run a build — same tsconfig, same flags
npx tsc --noEmit

# 3. Check for differences
# Most projects: zero changes needed

For VS Code users, install the dedicated TS 7 extension. Visual Studio enables it automatically based on workspace config.

The migration is designed to be uneventful. Same tsconfig.json, same CLI flags, same output. The team worked with Bloomberg, Canva, Figma, Google, Linear, Miro, Notion, Sentry, Slack, Vercel, and others through the preview period to make sure real-world adoption was smooth.

What This Means for the Ecosystem

Three things stand out:

1. CI costs drop meaningfully. If your CI spends significant time type-checking, TS 7 is a direct cost reduction. For large codebases, the savings from 8–12x faster type-checking can pay for the migration effort immediately. 2. The "TypeScript is slow" complaint dies. It was never really about absolute speed — it was about the experience of waiting for the compiler to catch up with your typing. With sub-second editor feedback on even the largest codebases, the perception shifts from "TypeScript adds friction" to "TypeScript is transparent." 3. Tooling gets a clean-slate moment. The new API in 7.1 isn't just a port of the old one — it's a redesign. The TS team gets to fix sharp edges that accumulated over a decade of backward compatibility. Tooling authors get to rebuild on a cleaner foundation. Short-term pain for long-term gain.

Should You Upgrade Today?

For most teams, the side-by-side setup is the sweet spot: get TS 7's build and editor speed while tooling continues on TS 6's API.

The Bottom Line

TypeScript 7 isn't a feature release. There are no new type-level gymnastics or syntax sugar. The value proposition is entirely about removing friction from the development loop.

If you've ever typed a few lines, waited for red squiggles, tabbed to another window, came back, and they still weren't there — TypeScript 7 fixes that.

If your CI pipeline's type-checking step is the longest item on the board — TypeScript 7 fixes that.

If your editor crashes silently and you don't notice until you've written 50 lines with no diagnostics — TypeScript 7 fixes that too.

It's a compiler that gets out of your way. That's the whole feature.

---

Install: npm install -D typescript@latest VS Code extension: TypeScript 7 Native Preview Announcement: devblogs.microsoft.com/typescript/announcing-typescript-7-0