TypeScript 7: The Native Compiler 10x Faster

If you've ever stared at your editor's little loading spinner waiting for a type error to appear, or watched a CI grind for long minutes on type-checking alone, this release is for you. TypeScript 7 goes straight at that daily point of friction.

TypeScript 7 is the first major version to ship a native compiler written in Go, delivering speed gains of 8x to 12x on full builds. Concretely, a project like VS Code goes from 125 seconds to about 10 seconds of build time, and the time to show the first error in the editor drops from 17.5 seconds to under 1.3 seconds. It installs simply via npm install -D typescript.

In this article, we'll break down what TypeScript 7 actually changes, how to install it, how to handle migration from previous versions, and above all which pitfalls to avoid so you don't break your existing projects.

What exactly is TypeScript 7?

TypeScript 7 is not a mere incremental evolution of the language. It's a complete native port of the compiler, rewritten from the TypeScript/JavaScript language to the Go language. Initially announced by Microsoft in March 2025 under the codename Project Corsa (the public repository is called typescript-go), this effort had a precise goal: cut compilation times by 10x and drastically reduce memory usage on large codebases.

Anders Hejlsberg, TypeScript's lead architect at Microsoft, summed up the promise this way: the native implementation dramatically improves editor startup, cuts most build times by 10x, and substantially reduces memory usage.

The crucial point to grasp: the port was carried out faithfully. The team did not reinvent the type-checking logic. It rewrote the code in Go while keeping exactly the same structure and logic as TypeScript 6.0. The result: the errors, messages, and locations are identical between the two compilers.

Why Go and not Rust or C++?

Go was chosen because it offers an excellent trade-off between native performance, syntactic simplicity, a built-in garbage collector (automatic memory management), and above all a robust concurrency model (goroutines and channels, Go's lightweight building blocks for running and coordinating tasks in parallel). This last point is decisive: it lets TypeScript 7 tap into shared-memory multithreading to parallelize parsing, type-checking, and code generation.

More importantly, the structure of the Go code stayed close to that of the existing TypeScript compiler, which allowed a near line-by-line port rather than a risky rewrite. By contrast, Rust's ownership model forbids cyclic structures without heavy workarounds, and the type-checker depends heavily on them: adopting it would have meant rethinking the core of the compiler, a multi-year undertaking with a real risk of behavioral drift.

Performance that changes a developer's daily life

The figures published by Microsoft on real open-source projects speak for themselves. Here are the compilation times compared between TypeScript 6 and TypeScript 7 (with the default of 4 checkers).

But the real stake isn't just the final build. TypeScript is everywhere in your day: autocompletion, find references, live diagnostics, refactoring, watch mode. That's where the friction is felt most.

A dramatic drop in memory

Contrary to the common belief that "faster = hungrier," TypeScript 7 uses less memory across a full compilation. The measured reductions range from -6% (sentry) to -26% (bluesky), with VS Code, for example, going from 5.2 GB to 4.2 GB (-18%).

Concrete real-world feedback from companies

Several large teams tested TypeScript 7 in real conditions before its release:

• Slack cut the wait time in its merge queue by 40%, bringing CI type-checking from 7.5 minutes to 1.25 minutes.
• Microsoft News Services saved 400 hours per month of waiting on CI builds.
• Canva saw the time to show the first error in the editor drop from 58 seconds to 4.8 seconds.
• Vanta measured a speedup of up to 9x on one of its largest projects.

On reliability, TypeScript 7's new language server reduced failing commands by more than 80% and server crashes by more than 60% compared to TypeScript 6.

What this actually changes for you, even solo

Beyond the numbers, the real gain lies elsewhere: the feedback loop. When type-checking goes from several seconds to a fraction of a second, you're not just changing a value in a table, you're changing the way you code. You iterate more often, you fix errors the moment you introduce them, and you stay in the flow instead of waiting.

For a solopreneur or a small team, that's time handed straight back. A CI that goes from 7 minutes to one minute means dozens of deploys a week that cost less and frustrate less. Less waiting mechanically means more shipped with the same resources.

And TypeScript 7 isn't an isolated case: it joins a groundswell of JavaScript tools being rewritten in native languages for speed (esbuild, SWC, Bun, Oxc...). The takeaway for your stack: slow tooling is no longer something you just put up with, it's become a selection criterion. It's worth looking, piece by piece, at what you could swap for a native alternative.

How to install and use TypeScript 7

Installation is the same as previous versions. You get the new native tsc executable directly in your workspace.

npm install -D typescript
npx tsc --version

For "nightly" builds (the development versions published every night), which were previously distributed via the @typescript/native-preview package (over 8.5 million weekly downloads), distribution now moves back under the standard package with the next tag:

npm install -D typescript@next

Editor support and LSP

TypeScript 7 introduces native support for the Language Server Protocol (LSP), the standard protocol that lets an editor talk to a code-analysis engine. In practice, your favorite editor (VS Code, Visual Studio, WebStorm) automatically benefits from the speed improvements and multithreading. VS Code already offers a dedicated extension, and Visual Studio enables TypeScript 7 automatically based on your workspace.

Controlling parallelization: --checkers, --builders, and --singleThreaded

This is one of the big technical novelties. TypeScript 7 now parallelizes parsing, type-checking, and code generation. Some steps parallelize easily (parsing, emitting), others don't (type-checking, which depends on the relative order of information).

The --checkers flag

TypeScript 7 creates a fixed number of type-checking "workers," each with its own view of the program. By default, that number is 4. You can adjust it:

# Use 8 checkers to speed things up on a big machine
npx tsc --checkers 8

# Drop to 1 (single-threaded) to save memory in CI
npx tsc --checkers 1

Increasing the number of checkers speeds up builds on multicore machines, but at the cost of higher memory usage. With --checkers 8, VS Code goes from 10.6s to 7.51s (16.7x faster than TypeScript 6).

The --builders flag

For monorepos (a single repository grouping several projects) using project references, --builders controls how many projects are compiled simultaneously during a --build:

npx tsc --build --builders 4

Watch out for the multiplier effect: --checkers 4 --builders 4 allows up to 16 simultaneous checkers, which can saturate your machine.

The --singleThreaded mode

For debugging, performance comparisons, or very resource-constrained environments, this flag disables parallelization entirely (parsing, checking, and emitting on a single thread):

npx tsc --singleThreaded

A fully rebuilt --watch mode

The --watch mode was rebuilt on a new foundation inspired by the file-watcher (the component that monitors changed files) of the Parcel bundler. The team ran into difficulties with cross-platform file watching in Go: the standard library offers no native API, and polling-based solutions (repeatedly checking files at regular intervals) were too expensive on large projects with many dependencies in node_modules.

The solution was to port Parcel's C++ watcher to idiomatic Go, with a few shims in assembly (small adaptation layers) to avoid introducing a dependency on a C++ toolchain. The result: stable, efficient, resource-friendly watching across all platforms.

npx tsc --watch

Migration: the behavior changes to know about

TypeScript 7 is compatible with TypeScript 6.0's type-checking. In practice, any code that compiles cleanly in 6.0 should compile identically in 7.0. But TypeScript 7 adopts 6.0's new defaults and turns deprecated options into hard errors.

The new configuration defaults

The rootDir and types changes are the most likely to catch you off guard. If your tsconfig.json sits outside a folder like src, add rootDir explicitly:

{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

For types, explicitly list the @types packages you depend on:

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

Options now disallowed (hard errors)

• target: es5 is no longer supported.
• downlevelIteration is no longer supported.
• moduleResolution: node/node10 removed (use nodenext or bundler).
• module: amd, umd, systemjs, none removed (use esnext or preserve).
• baseUrl removed: paths must be relative to the project root.
• moduleResolution: classic removed.
• esModuleInterop and allowSyntheticDefaultImports can no longer be false.
• alwaysStrict is always true.
• The module keyword can no longer be used in namespace declarations.

Running TypeScript 6 and TypeScript 7 side by side

Important point: TypeScript 7.0 does not yet provide a programmatic API (the interface that lets other tools drive the compiler through code). That will arrive with TypeScript 7.1. In the meantime, tools like typescript-eslint need programmatic access to the compiler. Microsoft has therefore published a compatibility package, @typescript/typescript6, which provides a tsc6 executable and re-exports the 6.0 API.

To run both versions side by side via npm aliases, edit your package.json:

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

With this setup, npx tsc will use TypeScript 7, while your linting tools keep relying on the 6.0 API.

A language feature: template literal types and Unicode

Beyond performance, TypeScript 7 now handles Unicode code points more naturally when inferring from template literal types (types computed from string patterns). A type like HeadTail that splits a string into head and tail correctly preserves Unicode characters made up of multiple units.

type HeadTail<S> = S extends `${infer Head}${infer Tail}`
  ? [Head, Tail]
  : [S, ""];

Best practices for adopting TypeScript 7

• Migrate to TypeScript 6.0 first to absorb the deprecations gradually before the big jump.
• Clean up your tsconfig: remove baseUrl, update moduleResolution, and explicitly declare rootDir and types.
• Tune --checkers to your environments: higher locally on a powerful machine, lower in CI.
• Pin a constant checker count across environments to guarantee reproducible results.
• Test your frameworks' compatibility (Vue, Svelte, Astro, Angular) before switching over in production.
• Use the compatibility package if your tools still depend on the compiler API.

Frequently asked questions

The gains range between 8x and 12x on full builds depending on the project and hardware. On machines with many cores using --checkers 8, some projects like VS Code reach 16.7x. Performance depends on project size, the number of CPU cores, and available memory.

No. The language syntax barely changes, and type-checking is structurally identical to TypeScript 6.0. What you'll mainly need to do is adjust your tsconfig.json to remove deprecated options and explicitly declare rootDir and types.

Yes, via the @typescript/typescript6 compatibility package and npm aliases. Since TypeScript 7.0 doesn't yet have a programmatic API (planned for 7.1), the tools that depend on it use the 6.0 API while tsc runs on version 7.

Not fully yet. Workflows using Vue, MDX, Astro, Svelte, or Angular's specialized template type-checking can't yet take full advantage of TypeScript 7. Check your framework's compatibility before migrating.

Go offers native performance, a garbage collector, simple syntax, and a powerful concurrency model (goroutines) ideal for multithreading. Its code structure was close enough to the existing TypeScript to allow a faithful port rather than a full rewrite, ensuring consistent results. By contrast, Rust's ownership model, incompatible with the cyclic structures the type-checker relies on, would have required rethinking the compiler from the ground up.