
TypeScript 7.0 Release Candidate shipped on June 18. Microsoft ran the new Go-based compiler against VS Code’s 1.5 million lines of TypeScript and got 7.5 seconds. That same codebase took 77.8 seconds on TypeScript 6.0. If you have been watching TypeScript 7 since the beta and waiting for a reason to pay attention, this is it: RC means the feature set is frozen. Stable ships in roughly four weeks.
What RC Means for Your Timeline
Beta releases are promises. Release candidates are commitments. Between RC and stable, Microsoft only accepts bug fixes — no new features, no spec changes, no revised defaults. The teams at Bloomberg, Canva, Figma, Google, Notion, Slack, and Vercel have been running pre-release builds for over a year. The RC is the signal that those validations are wrapping up and the compiler is ready. If you are planning a migration, now is the time to test, not after stable drops.
The Speed Gains Are Real
The 10x headline is backed by real production codebases, not microbenchmarks. The Go rewrite gets its speed from two independent sources. The first is native binary execution — the new compiler ships as a single native binary with no Node.js startup cost and no V8 JIT warmup. The second is parallelism. Go’s goroutines let the compiler parse, type-check, and emit multiple files simultaneously. The old JavaScript runtime could not safely parallelize type checking. Both sources contribute roughly equally to the total gain, which is why even a large improvement in one would not have produced a 10x result without the other.
| Project | TypeScript 6.0 | TypeScript 7.0 RC | Speedup |
|---|---|---|---|
| VS Code (1.5M lines) | 77.8s | 7.5s | 10.4x |
| Playwright | 11.1s | 1.1s | 10.1x |
| TypeORM | 17.5s | 1.3s | 13.5x |
One caveat worth noting: small single-file projects will see less dramatic improvement. Parallelism compounds with scale. The gains get larger as your project does.
Three tsconfig Changes That Will Break Your Build
The performance story is the headline, but the migration pain is where most developers will actually spend time. Three changes in TypeScript 7.0 are nearly guaranteed to break existing projects that have not been updated since the TypeScript 5 era.
baseUrl is removed. It was deprecated in TypeScript 6.0 with a compiler warning. In 7.0, it is gone. If your tsconfig uses baseUrl as a lookup root for module resolution — which is the default pattern in NestJS and many older configurations — you need to migrate. The fix is to remove baseUrl and prefix your paths entries with explicit relative paths:
// Before (TypeScript 6)
{
"compilerOptions": {
"baseUrl": "./src",
"paths": { "@app/*": ["app/*"] }
}
}
// After (TypeScript 7)
{
"compilerOptions": {
"paths": { "@app/*": ["./src/app/*"] }
}
}
Global @types packages no longer auto-resolve. The types option now defaults to an empty array. If your project relies on TypeScript automatically picking up @types/node, @types/jest, or @types/mocha from node_modules/@types, those will silently stop resolving global types. You need to list them explicitly under compilerOptions.types.
strict is on by default. Previously opt-in. Combined with module defaulting to esnext and target defaulting to ES2026, older projects will see a wall of new errors on first run. None of these defaults are wrong — they are the correct settings for a modern TypeScript project. But they will require attention in any codebase that has been coasting on lenient defaults. Also removed: moduleResolution: node and legacy module values (amd, umd, systemjs). Use nodenext or bundler.
One Caveat Before You Upgrade Tooling
TypeScript 7.0 does not include a stable programmatic API. Tools that import directly from the typescript package — typescript-eslint, ts-morph, ts-jest, ts-node, and custom compiler transformers — will break. The stable compiler API is planned for TypeScript 7.1, which is several months away. Microsoft’s recommended approach in the interim is a dual-version setup:
{
"devDependencies": {
"typescript": "^7.0.0-rc",
"typescript-legacy": "npm:@typescript/typescript6@^6.0.0"
}
}
Your tooling continues using the TypeScript 6 API via the legacy alias. Your builds and editor integrations use TypeScript 7. This is not elegant, but it is the correct path until 7.1 ships a stable compiler API.
How to Try It Now
npm install -D typescript@rc
For VS Code editor support, install the TypeScript Native Preview extension. The stable release is expected in approximately four weeks. The official RC announcement has full migration details, and the Hacker News discussion is tracking early adoption feedback. If you are on NestJS or any framework that relies on baseUrl, the NestJS issue tracker is already documenting the migration path.













