TypeScript 7.0: More Than Just Speed
TypeScript 7.0 rewrites the compiler in Go for 8-12x faster builds. But the real impact on daily development comes from the quietly changed defaults. Here's what actually matters in this upgrade.
On July 8, TypeScript 7.0 shipped. It's arguably the biggest infrastructure change in the project's history—the entire compiler has been ported from TypeScript/JavaScript to Go.
I tried it on a mid-sized project immediately. tsc --noEmit went from 4.3 seconds to 0.5. The perceptual difference is bigger than the numbers suggest: before, you'd hit Enter and tab over to the browser for a moment. Now, it's done before your finger lifts off the key.
But the performance story, while impressive, isn't what makes this release worth talking about.
Why Go
The TypeScript team's choice of Go is pragmatic rather than ideological. Go compiles to native machine code—no JIT warmup, full speed from the first instruction. Goroutines and shared memory are a natural fit for parallelizing compilation workloads. And a single statically-linked binary makes cross-platform distribution trivial: no runtime to install.
The porting strategy was "as faithful as possible"—preserve the structure and logic of the original codebase to keep the two compilers compatible. The speed comes from Go's native performance and shared-memory multithreading, not from changing how type-checking works.
The Numbers
The official benchmarks are refreshingly honest, measured on real-world projects:
| Project | TS 6 Build | TS 7 Build | 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 |
What's even better: memory usage went down too. vscode's peak compilation memory dropped from 5.2GB to 4.2GB—an 18% reduction. For CI pipelines and memory-constrained dev machines, this is real savings.
The default is 4 checker workers. Bumping to 8 can push vscode to 16.7x. For CI environments, the team recommends --checkers 1 to reduce redundant computation and memory.
Editor Experience: From "Grab Coffee" to Instant
The editor improvements tell an even better story. On the VS Code codebase itself, opening a file with errors used to take about 17.5 seconds before you'd see the first red squiggle. Enough time to grab coffee. TS 7 drops that to under 1.3 seconds.
Slack engineers reported that TS 7 eliminated 40% of their merge queue time, cutting CI type-checking from 7.5 minutes to 1.25 minutes. Canva saw first-error-in-editor drop from 58 seconds to 4.8 seconds. Microsoft News Services saved 400 hours a month in CI wait time.
These aren't "it feels faster" anecdotes. These are chunks of fragmented attention being stitched back together.
The Defaults That Changed
The speed improvements are visible and celebrated. The defaults that silently changed? Those are the ones that will break your CI.
strict: true is now the default. All strict checks—noImplicitAny, strictNullChecks, and the rest—are on by default. New projects benefit immediately. Existing projects that never turned on strict will wake up to a sea of red.
module: "esnext" is now the default. CommonJS output is no longer the assumption. If your config relied on the implicit CommonJS default, you need to set it explicitly.
rootDir: "./" is now the default. Previously, many projects worked fine without setting rootDir. Now, if your tsconfig.json lives at the project root but your source is in src/, you must set rootDir: "./src" explicitly.
types: [] is now the default. This one has the biggest blast radius. @types/node, @types/jest, and other ambient type packages no longer auto-load. If your code uses process.env or Buffer without explicitly declaring node in the types array, it will break.
{
"compilerOptions": {
"types": ["node", "jest"]
}
}
stableTypeOrdering: true and it can't be turned off. Generated .d.ts files are now deterministic regardless of compilation order. Library authors will love this—cleaner diffs. If your code somehow depends on implicit type ordering, you'll need to adjust.
What's Gone for Good
Features deprecated in TS 6 are now hard errors in 7.0:
target: es5is gone. ES5 compilation target officially retires.module: amd / umd / systemjs / noneare gone. Useesnextorpreserve.moduleResolution: node / node10 / classicare gone. Usebundlerornodenext.baseUrlis gone.pathsshould use project-root-relative notation.esModuleInteropandallowSyntheticDefaultImportscan no longer be set to false.- The
assertskeyword on imports must be changed towithto align with the ECMAScript Import Attributes spec.
The direction is clear: TypeScript is fully committing to the modern ECMAScript ecosystem. If you're maintaining a legacy project that depends on AMD modules or ES5 output, this upgrade is more than npm install.
Migration Path
If your project is already on TS 6 with strict mode enabled, upgrading to 7 should be relatively smooth. Check these things:
- Does
rootDirneed to be set explicitly? - Does the
typesarray declare all needed ambient type packages? - Are there any config entries targeting ES5 or legacy module systems?
- Do
pathsentries use project-root-relative notation (no longer relying onbaseUrl)?
If you're still on TS 5 or earlier, go to TS 6 first, then 7. TS 7 doesn't ship with a programmatic API yet (that comes in 7.1), so tools like typescript-eslint that depend on the TS API need the @typescript/typescript6 compatibility package for now. Projects using embedded languages like Vue, MDX, Astro, or Svelte also need to stay on TS 6 until 7.1—these frameworks depend on tooling integrations through Volar and similar.
Bottom Line
What I like most about TypeScript 7.0 isn't the flashy new syntax features—it's that there aren't any. The team focused on the plumbing. The compiler is faster, the editor is snappier, memory usage is down. These improvements won't make for viral tweets, but they'll save you time every single day.
And the Go rewrite means the TypeScript compiler can now run without a Node.js runtime. The implications for future tooling are significant—imagine not needing to install Node just to run tsc in CI.
Porting 2 million lines of TypeScript to Go isn't a small undertaking. The TypeScript team did solid, unglamorous work here, and it shows.