TypeScript 7 Is Here: Why a 10x Faster Compiler Changes Your Workflow

This week TypeScript 7.0 topped Hacker News — 703 points and nearly 300 comments (discussion here). And rightly so. This isn't a minor release with a handful of new utility types. It's the first version running on the compiler that has been fully rewritten in Go. The payoff: up to 12x faster type-checking and builds.

As a freelance .NET developer who switches between C# on the backend and TypeScript on the frontend every day, there's one thing I've grumbled about for years: tsc is slow. Not broken — just slow enough to break your flow. In this article I look at what actually changes, which breaking defaults are going to bite you, and whether you should migrate today.

The numbers: this is not marketing

Microsoft ran the new compiler against real, large codebases. The figures from the announcement speak for themselves:

Project	TypeScript 6	TypeScript 7	Speedup
VS Code	125.7s	10.6s	11.9x
Sentry	139.8s	15.7s	8.9x
Playwright	12.8s	1.47s	8.7x

Memory usage drops between 6% and 26%. And perhaps more important for your day-to-day: opening a file with errors in the editor went from 17.5 seconds to under 1.3 seconds. That's the difference between waiting for the squigglies and the squigglies waiting for you.

Why can Go do this and the old compiler couldn't? The original tsc is written in TypeScript itself and runs on a single Node.js thread. Elegant for self-hosting, but single-threaded and bound to V8's garbage collector. The Go port compiles to native code and uses real multithreading to type-check independent modules in parallel. For .NET folks the analogy is easy: it's like going from a purely interpreted layer to AOT-compiled, parallelised code.

What this means for CI/CD

Here's where it gets concrete. In many pipelines, tsc --noEmit is the slow step that holds your build hostage. A monorepo with 400k lines of TypeScript that used to spend two minutes type-checking will soon do it in fifteen seconds. That changes your entire mindset around type-checking.

The old trade-off was: do I run type-checking on every push, or only on the PR? At ten seconds you no longer have to make that call. You just turn it on everywhere. A typical GitHub Actions step goes from necessary evil to something you barely feel:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      # Before: 90-120s. With TS7: ~10-15s on the same codebase.
      - run: npx tsc --noEmit

For my own SaaS products (CronGuard, CertGuard) I run a shared TypeScript frontend against a .NET backend. The type-check step was always the longest in the pipeline — longer than dotnet build and the tests combined. With TS7 that ratio flips completely. It's not just faster; it changes where your attention goes: suddenly the bottleneck is your test suite again, right where it belongs.

The breaking defaults that will bite you

Speed is the sales pitch, but the release notes hide something more important: TypeScript 7 revisits several defaults. If you carry an old tsconfig.json over blindly, you'll get surprises. The key changes:

strict is now on by default. Finally. But if your codebase has never run under strict mode, it's about to rain null errors.
module now defaults to esnext. CommonJS is no longer the assumption.
types now defaults to []. Previously every package under node_modules/@types was pulled in automatically. Not anymore — you have to be explicit.
rootDir defaults to ./. This can change your output structure if you relied on it.
Removed flags: ES5 as a target is gone, along with downlevelIteration and the legacy module systems AMD, UMD and SystemJS.

That types: [] change is the silent killer. I've seen projects that leaned on implicitly loaded @types/node or @types/jest without ever declaring it in the config. Under TS7 that breaks quietly: types that were there simply aren't anymore. So be explicit:

// tsconfig.json — TS7-friendly and explicit
{
  "compilerOptions": {
    "target": "es2023",
    "module": "esnext",
    "moduleResolution": "bundler",
    "strict": true,
    "types": ["node", "vitest/globals"], // explicit, no more auto-include
    "verbatimModuleSyntax": true,
    "noEmit": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}

My advice: don't treat the migration to strict mode as a big bang. Turn strict: true on, count the errors, and clear them module by module. For a large legacy codebase you can temporarily isolate strictNullChecks with per-file overrides, but the real goal is: green everywhere.

Coexistence: 6 and 7 side by side

Microsoft has been sensible here. You don't have to switch all at once. There's a @typescript/typescript6 package that lets you run both versions side by side. That matters, because there's a significant caveat: TypeScript 7.0 ships without a public API. Version 7.1 will bring a new (and different) API.

That sounds like a detail, but it's the reason frameworks that embed TypeScript — Vue, Svelte, Astro, Angular — can't move yet. They use tsc's programmatic API internally to type-check templates. Until that API exists, those teams have to stay on TypeScript 6. If you use such a framework, the recommendation is clear: stay on 6.0 for that workflow, and use 7 for your standalone packages and CLI checks.

For a typical React or Next.js frontend without an embedded compiler, you're fine. For an Angular monorepo: hold your horses.

A concrete migration path

Here's how I'd approach it at a client, in ascending order of risk:

First run only tsc --noEmit with TS7 in CI, alongside your existing build. Pure observation: what errors surface from the stricter defaults? Don't fail anything yet.
Fix the types and module errors. This is mostly mechanical: explicit types array, cleaning up imports, respecting verbatimModuleSyntax.
Turn on strict mode module by module. Start with new code and frequently changed files.
Only once CI is green: make TS7 the source of truth for your type-check and emit.

A detail people often forget: your editor. VS Code has to use the new language service, otherwise you'll still see the old (slow) tsc in the editor while your pipeline already runs the fast one. Pin the workspace version:

// .vscode/settings.json
{
  "typescript.tsdk": "node_modules/typescript/lib",
  "typescript.enablePromptUseWorkspaceTsdk": true
}

The C# parallel nobody draws

What strikes me most is how this rhymes with what's been playing out in the .NET world for years. Roslyn — the C#/VB compiler — is also written in the language it compiles (C#), and that works fine because the CLR is a serious, optimised runtime. Node.js/V8 is fast, but it wasn't built for the compute-heavy, broadly parallel workload of type-checking a million lines.

The choice of Go over C# or Rust generated a lot of heat on Hacker News. Anders Hejlsberg — the architect behind both C# and TypeScript — picked Go because its memory model and control flow sit close to the existing TypeScript codebase, which made a largely mechanical port possible instead of a full redesign. For a codebase this size, "we can port it one-to-one" is a huge risk-reduction argument. I get the call, even if the .NET part of me secretly hoped for a NativeAOT C# port.

The deeper lesson is universal, regardless of language: compiler performance is developer performance. Every second you shave off tsc or dotnet build gets multiplied by the number of times per day each developer waits on it. On a team of ten building a hundred times a day, that adds up to hours. That's precisely why the industry spent years on this rewrite.

Should you migrate today?

My sober take:

Greenfield or a clean React/Next frontend? Start on TS7 right away. The speed win is immediately tangible and you have no legacy config to trip over.
Large codebase not yet on strict mode? Add TS7 as a shadow check in CI, gather the errors, and migrate in a controlled way. Don't force it.
Angular, Vue, Svelte or Astro with an embedded compiler? Stay on TypeScript 6 until 7.1 lands the stable API. Don't push it.

The real win isn't that your build is ten seconds faster. It's that type-checking becomes so cheap you can turn it on everywhere without thinking — in pre-commit hooks, on every push, in every watch mode. That shifts the cost-benefit calculus from "type-checking is expensive, so we look the other way" to "it's free, so we do it everywhere." And that's exactly the kind of change that makes your codebase measurably healthier a year from now.

TypeScript 7 isn't exciting because of new language features. It's exciting because it makes a fundamentally slow step in your workflow nearly free. Leaps like that are rare — take it.

Sources: Announcing TypeScript 7.0 — Microsoft DevBlogs · Hacker News discussion