MLog

A bilingual blog crafted for our own voice

Back to posts
Tech#TypeScript#Go#compiler

TypeScript 7.0 First Impressions: 10x Faster Builds After the Go Rewrite

Published: Jul 12, 2026Reading time: 6 min

TypeScript 7.0 ports the entire compiler from TypeScript/JavaScript to Go, delivering 8-12x faster builds. Here's what the migration actually looks like—what breaks, what gets better, and whether you should upgrade now.

On July 8, 2026, the TypeScript team shipped version 7.0. They rewrote the entire compiler in Go.

I spent a weekend migrating two projects. Here's what I learned: how much faster it actually is, what broke during migration, and which projects should wait.

Why Go?

The old compiler was written in TypeScript, running on Node.js. That architecture came with built-in constraints: JIT warm-up, single-threaded bottlenecks, high memory usage. On large codebases, type-checking could take minutes. In the editor, you'd open a file and wait 10-15 seconds to see the first error squiggle.

The team chose Go for pragmatic reasons:

  • Compiles to native machine code. No JIT warm-up, full speed from the start.
  • Goroutines map naturally to parallel compilation tasks. Multi-core utilization is excellent.
  • Ships as a single binary. No Node.js runtime dependency.

The porting strategy was deliberately conservative: faithfully replicate the original logic to preserve type-checking semantics, then layer parallelism on top using Go's concurrency primitives.

Real-world performance

Here's the official benchmark data, which matches what I saw on my own projects:

Project TS 6 build time TS 7 build time Speedup
vscode 125.7s 10.6s 11.9x
sentry 139.8s 15.7s 8.9x
bluesky 24.3s 2.8s 8.7x
playwright 12.8s 1.47s 8.7x
tldraw 11.2s 1.46s 7.7x

Bump --checkers to 8 on a high-core machine and vscode hits 16.7x.

My own project—about 300 files, medium size—went from 23 seconds to 2.4 seconds on tsc --noEmit. Not a massive monorepo, but the gap is large enough to change how I work. Before, I'd switch tabs while waiting for type-checking. Now the result is there before I can blink.

Memory usage dropped too. vscode's peak went from 5.2GB to 4.2GB—an 18% reduction. That matters for CI runners and 16GB laptops.

Editor experience: no more waiting

The editor improvements caught me off guard. Previously, opening a large TypeScript file in VS Code meant waiting 10–15 seconds for the first red squiggly. Now it's 1–2 seconds. You open a file and the diagnostics are just there.

According to the team's telemetry, VS Code's own first-error latency dropped from 17.5s to under 1.3s. Canva went from 58s to 4.8s. Slack reported that their large codebase was previously "basically unusable" in the editor—developers relied entirely on CI for full type-checking. Now it loads in seconds, and local type-checking is actually practical.

The language server was also rewritten from scratch as a multi-threaded LSP server. The team reports over 80% fewer command failures and over 60% fewer server crashes compared to the TS 6 language server.

Migration: what broke

The official recommendation is to upgrade to TS 6 first, then go to 7. If your project compiles cleanly under TS 6 with no deprecation warnings, the jump to 7 should be smooth. If you're still on TS 5 or earlier, do this in two steps.

Here's what I actually ran into:

1. rootDir default changed

TS 7 defaults rootDir to ./ (project root) instead of inferring it. If your source lives in src/, you need to be explicit:

{
  "compilerOptions": {
    "rootDir": "./src"
  }
}

2. types no longer auto-loaded

Previously, @types/node and @types/jest were picked up automatically. TS 7 defaults to types: []. Declare them explicitly:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

3. Deprecated options became hard errors

These broke in my projects:

  • target: "es5" — ES5 is officially retired. If you still need to support legacy browsers, you'll need a separate transpilation step.
  • moduleResolution: "node" — must switch to "bundler" or "nodenext".
  • esModuleInterop: false — no longer allowed; it's always on now.

Path aliases also changed: baseUrl is gone entirely. Use paths with project-root-relative patterns instead.

4. JSDoc type annotations need updates

If you're using JSDoc for types (.js files with type annotations), a few patterns no longer work:

  • @enum is no longer recognized—use @typedef instead.
  • Closure-style function(string): void syntax is gone—use (s: string) => void.
  • The postfix ! type assertion is no longer supported.

These changes mostly affect projects that rely heavily on JSDoc rather than .ts files.

Who can't upgrade yet

This is the biggest caveat right now: Vue, Svelte, Astro, and MDX projects cannot use TS 7 in the editor.

These frameworks embed TypeScript into their own compilers and language services, which requires calling TypeScript's programmatic API. TS 7.0 doesn't expose a stable API yet. The team has committed to delivering this in TS 7.1, expected around October 2026.

Angular projects can partially adopt it: use TS 7 on the command line for fast project-wide checking, and keep TS 6 in the editor for template type support.

If you're on React, Next.js, or plain Node.js backends, you're good to go.

Running both versions side by side

You can install TS 6 and TS 7 together using npm aliases:

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

With this setup, npx tsc uses TS 7 for compilation, while tools like typescript-eslint continue using TS 6's API. The team also published @typescript/typescript6 as a compatibility package with a tsc6 command and full TS 6 API exports.

Should you upgrade?

Yes, with conditions.

If your project is pure TypeScript—React, Node, Next.js—doesn't depend on Vue/Svelte embedded frameworks, and already compiles cleanly under TS 6: upgrade now. Builds go from minutes to seconds. Editor feedback goes from "wait for it" to "instant." This isn't a marginal improvement; it changes how you work.

If you're still on TS 5 or earlier: go to TS 6 first. Deal with the default changes and deprecation warnings there, then move to 7.

If you're on Vue, Svelte, or Astro: wait for 7.1. No editor type hints defeats the purpose.

TypeScript 7.0 isn't the finish line. 7.1 will close the API gap, and after that the team returns to feature work. The compiler rewrite was the heavy lift. The fun part starts now.