News

TypeScript 7.0 shipped on 8 July 2026, and the headline is simple: the compiler is now written in Go instead of in TypeScript itself, and it builds roughly 10 times faster. For anyone maintaining a large Vue, Nuxt or React codebase, this is the biggest change to the everyday TypeScript workflow in years - not new syntax, but a new engine under the same tsc command.

Nothing about how you write types changes. Your .ts files, your tsconfig.json and your type errors stay the same. What changes is how quickly the compiler parses, checks and emits your project, and how responsive your editor feels while you work. This guide covers what actually changed, the real benchmark numbers, how to try it today, and the honest trade-offs before you migrate.

What actually changed

The project, codenamed Corsa, is a port rather than a fresh rewrite. Microsoft's team, led by TypeScript lead architect Anders Hejlsberg, moved the existing algorithms and data structures over to Go so that type-checking behaviour stays identical: the same inference, the same errors. Go was chosen over Rust largely because TypeScript's syntax trees and symbol tables rely on cyclic references, which fit Go's garbage-collected model and goroutines far better than Rust's ownership rules.

The speed comes from two things. Native compiled code is simply faster than the old JavaScript-based compiler, and the new compiler runs work in parallel: parsing, type checking and emitting can happen across multiple threads instead of one. Memory use drops by roughly half compared with the JavaScript compiler, and the editor language service loads large projects much quicker.

The speed, in real numbers

Microsoft published before-and-after numbers on real projects. Compiling the VS Code codebase (about 1.5 million lines) went from 77.8 seconds to 7.5 seconds, a 10.4x speedup. Playwright compiled about 10x faster and TypeORM around 13.5x. These are full clean builds, the kind that dominate CI time and slow down local type-checks on big repositories.

• TypeScript 7.0 (released 8 July 2026) replaces the JavaScript-based compiler with a native port written in Go: same types, new engine
• Roughly 10x faster full builds (VS Code 77.8s to 7.5s), about 8x faster editor project loading and around 50% less memory
• It is a port (codename Corsa) led by Anders Hejlsberg: identical type-checking behaviour, now parallelised across threads
• Installs and runs as tsc; nightly previews still use the tsgo name under @typescript/native-preview
• Breaking changes: es5 target, node resolution mode, baseUrl and AMD/UMD/SystemJS removed; some defaults (rootDir, types) changed
• Tooling on the programmatic API (typescript-eslint, ts-morph, custom transformers) needs a later 7.x release, so adopt side by side for now

The editor gains matter just as much day to day. Loading a large project in the language service dropped from about 9.6 seconds to 1.2 seconds, roughly 8x. That is the difference between waiting for IntelliSense to wake up and having autocomplete, go-to-definition and error underlines respond almost instantly on a codebase that used to feel sluggish.

How to try it today

Installation is deliberately boring: the native compiler installs from the normal package and runs as tsc, so most projects can try it with a single dependency bump. Earlier previews shipped a separate tsgo binary, and nightly builds are still published under @typescript/native-preview with that name, but the release itself is just tsc. New flags let you tune parallelism, for example the number of type-checking workers, or disable it with a single-threaded mode when you need reproducible serial output.

A safe way to adopt it is side by side. You can keep the previous 6.x compiler installed under an alias (commonly invoked as tsc6) while pointing your main build at 7.0. That lets you run the fast new compiler for builds and editing while any tool that still depends on the older, stable programmatic API keeps working untouched.

Breaking changes to watch for

There are real breaking changes, so read the release notes before upgrading in place. Several long-deprecated options are gone, including the es5 target, the old node module-resolution mode, baseUrl, and the AMD, UMD and SystemJS module formats. Some defaults changed too, such as rootDir and the default set of ambient type packages, which can surface new errors in configs that relied on the old implicit behaviour.

The honest trade-offs

The speed win is real, but the ecosystem needs a beat to catch up. Tools built on TypeScript's programmatic API (typescript-eslint, ts-morph, custom compiler transformers) depend on interfaces that are only slated to stabilise in a later 7.x point release. Until then, teams that lean heavily on those tools may want to run 7.0 for builds and editing while keeping the 6.x line available for the parts of the toolchain that are not ready yet.

It is also worth keeping expectations grounded: TypeScript 7 makes the compiler faster, not your shipped app. The output is still the same JavaScript running in the same browsers and Node versions, so runtime performance is unchanged. What you get is shorter build and CI times and a snappier editor, which on a large front-end codebase is exactly where the friction has been. For most Vue, Nuxt and React teams the practical move is to try it on a branch, watch for the removed options, and adopt it for the build and editor once the numbers check out.