TypeScript 7.0 RC: The Go-Native Compiler Has Landed

TypeScript 7.0 RC landed on June 18, 2026, and it rewires the one thing every TypeScript team feels every day: how long type-checking takes. The compiler is now written in Go instead of TypeScript/JavaScript, and Microsoft reports the native port is often roughly 10x faster than TypeScript 6.0 — turning multi-minute type-checks on large codebases into single-digit-second runs.

This is a Release Candidate, not the general-availability build. Microsoft has announced that the stable GA release is expected within about a month of the RC, so treat 7.0 as production-grade for evaluation and CI experiments today, with the formal stable cut still ahead. The headline performance numbers below are Microsoft-stated benchmarks against real production codebases — we attribute each one and cite the source.

This guide covers what the RC actually ships, why the team chose a Go port over a Rust rewrite, the install commands (typescript@rc, the side-by-side TypeScript 6.0 alias, and the nightly tsgo binary), the new parallel-execution flags, the tsconfig changes that catch teams off guard, and the programmatic-API gap that means typescript-eslint, ts-morph, and custom transformers should wait for 7.1.

On June 18, 2026, Microsoft published the TypeScript 7.0 Release Candidate on its developer blog. The RC is available immediately on npm, and Microsoft has stated that the stable general-availability release is expected within approximately one month of the RC. That is the team’s own estimate of the timeline — it is not a fixed, published GA date, so plan around “next month-ish,” not a specific day.

The substance of the release is a single, enormous change: the entire compiler and language service have been reimplemented in Go. This is the project Microsoft announced in March 2025 under the internal codename Project Corsa, with the legacy JavaScript-based codebase referred to as Strada. The RC is the first build the team is comfortable recommending for broad production evaluation, after more than a year of pre-release testing on million-line codebases.

Most coverage frames TypeScript 7.0 as a rewrite. That framing undersells the most important property of the release: the team did not redesign the type-checker, they transplanted it. Project Corsa moved the existing structure file-by-file out of the JavaScript Strada codebase and into Go, deliberately preserving the same algorithms, the same data structures, and therefore the same type-checking semantics. A from-scratch rewrite could not make that promise — a port can.

That distinction is the basis for Microsoft’s production-ready assertion. Because the behavior is intended to be identical, code that compiles cleanly under TypeScript 6.0 is expected to compile identically under 7.0. The team also ran the Go compiler against its decade-old test suite and its internal fuzz-testing rigs to validate that equivalence, reporting in a December 2025 progress checkpoint that only 74 test-case discrepancies remained, all attributed to known incomplete work or intentional specification changes.

There is one consequential side effect of the port. For 14 years TypeScript was a self-hosted compiler — it compiled its own source code. With the Go port, that is no longer true: contributing to the compiler now requires Go knowledge rather than TypeScript knowledge. Microsoft has framed this as a deliberate architectural tradeoff accepted in exchange for the performance gains. For most teams it changes nothing about how they consume TypeScript; for would-be compiler contributors, it changes the entry requirements entirely. This is part of TypeScript’s evolution from a JavaScript-superset experiment into infrastructure that has to scale to the largest codebases on earth.

Microsoft’s headline framing is careful, and so is ours: the compiler is often about 10 times faster, not uniformly 10x on every project. The gain scales with codebase size, because two separate effects stack. Roughly 3–4x comes from native binary execution — there is no Node.js or V8 JIT warm-up overhead — and another roughly 2–3x comes from shared-memory parallel threads (Go goroutines) that split type-checking work across cores. Small single-file projects see less; the largest projects see the most.

The chart below shows the speedup across four real production codebases, all Microsoft-stated except where noted. The VS Code number is the flagship: a 1.5-million-line TypeScript codebase whose full tsc run drops from 77.8 seconds to 7.5 seconds.

Two more numbers matter beyond raw tsc time. First, editor project-load time — measured on VS Code’s own codebase — improves about 8x, from 9.6 seconds to 1.2 seconds, because the language server itself is now Go-native, not just the CLI. Second, Microsoft reports memory usage is roughly halved versus the JavaScript compiler, with further optimization anticipated. For teams running type-checks in CI/CD pipeline design, the practical read is faster feedback loops and lower runner-minute costs — though specific cost savings vary by workload and should be measured, not assumed.

The choice of Go over Rust is a genuinely useful architectural lesson, and most coverage skips the reasoning. The TypeScript compiler’s internal data structures — abstract syntax trees and symbol tables — are full of cyclic references. Rust’s ownership model prohibits cyclic structures without significant workarounds, so adopting Rust would have meant restructuring the type-checker from the ground up: a multi-year effort that would also risk subtle behavioral drift from the existing compiler.

Go’s garbage-collected, shared-memory model maps naturally onto that existing architecture. Cyclic references are fine, and goroutines give cheap shared-memory parallelism across a single symbol table. That combination is what made a roughly one-year port with identical semantics achievable, instead of a years-long rewrite. The lesson generalizes: when you are porting a large system whose performance depends on a specific in-memory shape, the language whose memory model matches that shape can be worth more than the language with the best raw benchmarks.

The install path changed at the RC. During the beta and nightly phases, the native compiler was only available under @typescript/native-preview with a binary named tsgo. As of the RC, the recommended path is the standard package: npm install -D typescript@rc. The tsc binary from that package is the Go-native compiler — there is no separate tsgo name to invoke in the RC. The tsgo binary persists only in the nightly @typescript/native-preview builds.

Because the stable programmatic API is not in 7.0 (more on that below), most teams will run 6.0 and 7.0 side-by-side during the transition. Install TypeScript 6.0 alongside the RC with npm install -D typescript@npm:@typescript/typescript6, which provides a tsc6 executable for any tooling that still needs the 6.0 toolchain while you migrate.

The 2–3x parallelism component of the speedup is configurable, and the RC exposes three new compiler flags to control it. The defaults are sensible for most machines, but if you are tuning type-check jobs on a CI runner with a known core count and memory ceiling, these are the knobs that matter.

The --builders flag is where monorepos win twice. Faster per-project type-checks compound with parallel project-reference builds across the dependency graph, which is exactly the bottleneck that dominates large workspace builds. If you are weighing how to structure parallel builds across packages, the same calculus applies to your monorepo build strategies — the Go-native compiler shifts where the wall-clock time goes, so re-benchmark your task graph rather than assuming the old hotspots still hold. Separately, --watch mode is rebuilt on a Go port of Parcel’s file-watcher, replacing the old polling approach and significantly reducing CPU spikes in large node_modules trees.

TypeScript 7.0 adopts all of the strict defaults introduced in 6.0 as hard requirements, and turns 6.0’s deprecations into compile errors. If your team upgraded through 6.0, most of this is already behind you. If you jumped from 5.x straight to 7.0, two changes in particular tend to break builds silently before anyone reads the release notes.

• rootDir now defaults to ./. If your tsconfig.json sits above a src/ folder, you must add "rootDir": "./src" explicitly, or your output directory structure breaks.
• types now defaults to an empty array. Ambient globals from @types/node, @types/jest, @types/mocha and similar are no longer auto-included — list each one explicitly in types or the globals disappear.

On top of those, several long-deprecated options are now hard removals: target: es5 (es2015 is the new minimum), moduleResolution: node / node10 (use nodenext or bundler), the amd / umd / systemjs / none module formats, baseUrl (use paths with relative paths), and esModuleInterop: false. JavaScript-file and JSDoc support also tightened — values can no longer substitute for types, the @enum tag is gone, and Closure-style JSDoc syntax is removed.

The single most practical question for a professional team is not “is 7.0 fast” — it is “which parts of my toolchain can move now, and which are blocked until 7.1.” The table below maps each common tool to its status in the RC, the recommended action, and whether a workaround exists today.

Almost every “upgrade to TypeScript 7” walkthrough stops at npm install -D typescript@rc and moves on. For a professional team, the most consequential detail is the one those walkthroughs skip: the stable programmatic API — the surface that typescript-eslint, ts-morph, and custom transformers build on — is not in TypeScript 7.0. Microsoft has targeted it for TypeScript 7.1, which the team describes as at least several months away.

Practically, that means a naive upgrade can leave your linter and codegen broken even though your builds got faster. The recommended workaround is to alias the TypeScript 6.0 package in package.json (for example, "typescript": "npm:@typescript/typescript6@^6.0.0") and install TypeScript 7.0 under a separate alias such as typescript-7. The new tsc binary then runs your 7.0 builds while ESLint continues to type against the stable 6.0 API. This is exactly the kind of side-by-side, reversible change that suits a phased rollout strategy — flip the build over per-package, keep the safety net in place, and remove the 6.0 alias only once 7.1 lands.

The flip side is genuinely good news for teams building TypeScript tooling. The new LSP-based language server can serve multiple concurrent requests across threads and exposes the full feature set — auto-imports, expandable hover tooltips, inlay hints, code lenses, go-to-source-definition, JSX linked editing, semantic highlighting, and import sorting — through a standard JSON-RPC protocol rather than the old proprietary tsserver protocol. If you are building TypeScript tooling today, the faster type-checking and standard LSP surface are a direct tailwind — just architect around the 7.1 API timeline rather than against the RC.