TypeScript 7.0: 10x Faster Builds and What Developers Need to Know

TypeScript 7.0 is a native port of the TypeScript toolchain, written in Go, that delivers roughly 8x to 12x faster full builds on the large open-source projects tested by Microsoft. It also brings a multithreaded compiler, a new Language Server Protocol (LSP) implementation, a rebuilt watch mode, and lower memory use in the published benchmarks.

TypeScript 7.0 at a Glance

Why TypeScript Was Rewritten in Go

Earlier TypeScript compilers were written in TypeScript and ran on a JavaScript runtime. That design made the compiler portable and contributed to TypeScript's success, but it also limited how efficiently the toolchain could use modern hardware.

TypeScript 7.0 moves the compiler and language service to native Go code while preserving the structure and behavior of the original implementation as closely as possible. This gives the toolchain three important advantages:

• native execution speed
• shared-memory multithreading
• new opportunities to optimize parsing, type-checking, emitting, and project builds

This is why TypeScript 7.0 feels different from a typical language release. The source code you write is mostly the same. The machinery that understands it has changed.

How Much Faster Is TypeScript 7.0?

Microsoft measured full build times across five large open-source projects:

Those results are benchmarks, not a promise that every repository will be exactly 10 times faster. Your improvement will depend on project size, dependency structure, available CPU cores, memory, and compiler settings.

The practical benefit goes beyond CI. In Microsoft's VS Code test, the time between opening the editor and seeing the first error fell from about 17.5 seconds to under 1.3 seconds. Faster diagnostics, completions, find-all-references, and watch builds shorten the feedback loop throughout the day.

Memory use also fell by 6% to 26% across the five published build tests. That matters in large monorepos and constrained CI runners, where faster software that consumes much more memory would simply move the bottleneck.

Multithreading Is the Real Architectural Shift

TypeScript 7.0 can run parsing, type-checking, emitting, and project builds in parallel. It uses four type-checker workers by default.

Three new experimental flags provide control:

• --checkers changes the number of type-checker workers
• --builders changes how many project-reference builds can run concurrently
• --singleThreaded disables compiler parallelism

For example:

npx tsc --checkers 8
npx tsc --build --checkers 4 --builders 2
npx tsc --singleThreaded

Start with the defaults. Benchmark realistic workloads before changing them, and use the same settings in development and CI if consistent results are important.

The New Watch Mode and Editor Experience

Microsoft also reports that, compared with TypeScript 6.0, the new language server reduced failed commands by more than 80% and crashes by more than 60% in its telemetry.

The Biggest Compatibility Limitation: No Compiler API Yet

That limitation affects tools that import TypeScript as a library or embed its language service. The TypeScript team specifically notes that Vue, MDX, Astro, Svelte, and specialized Angular template tooling will generally need TypeScript 6.0 for now.

This does not mean those projects cannot benefit at all. Some teams may use TypeScript 7.0 for command-line project checks and TypeScript 6.0 for framework tooling or editor support. The correct setup depends on the framework and its current integration.

Before upgrading, audit these areas:

• ESLint and typescript-eslint
• framework language servers and editor extensions
• build tools or loaders that call the compiler API
• code-generation tools based on the TypeScript AST
• custom scripts that import typescript

If your toolchain imports the compiler directly, plan for a side-by-side setup or wait for its maintainer to confirm support.

Important TypeScript 6.0 Defaults Now Apply

TypeScript 7.0 aims to match TypeScript 6.0's type-checking and command-line behavior. The safest path is therefore TypeScript 5.x → TypeScript 6.0 → TypeScript 7.0, fixing migration issues at each step.

Notable defaults include:

• strict is now true
• module defaults to esnext
• noUncheckedSideEffectImports is true
• rootDir defaults to the project root
• types defaults to an empty list
• stableTypeOrdering is always enabled

Two changes are especially likely to surprise existing projects.

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

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

Deprecated Options That Now Fail

TypeScript 7.0 turns several TypeScript 6.0 deprecations into hard errors or no-op behavior. Among the most important:

• target: "es5" is no longer supported
• moduleResolution: "node" and "node10" are removed; use "nodenext" or "bundler"
• moduleResolution: "classic" is removed
• module: "amd", "umd", "systemjs", and "none" are removed
• baseUrl is removed; make paths entries relative to the project root
• downlevelIteration is removed
• esModuleInterop and allowSyntheticDefaultImports cannot be false
• alwaysStrict is always enabled

One Small Language Behavior Change: Better Unicode Handling

Template literal type inference now preserves complete Unicode code points instead of splitting some characters into UTF-16 surrogate pairs.

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

type Result = HeadTail<"😀abc">;
// TypeScript 7.0: ["😀", "abc"]

How to Upgrade to TypeScript 7.0 Safely

Use a branch and measure your current baseline before changing the compiler.

1. Move to TypeScript 6.0 first

2. Record real build and editor baselines

Measure the commands your team actually runs:

time npx tsc --noEmit
time npx tsc --build

Also note CI duration, peak memory, watch rebuild time, and editor startup behavior.

3. Install TypeScript 7.0

npm install --save-dev typescript
npx tsc --version

Commit the lockfile so local development and CI use the same compiler version.

4. Test more than one successful build

Validate:

• clean builds and incremental builds
• --noEmit checks
• declaration output if you publish libraries
• project references in monorepos
• watch mode
• editor navigation, rename, imports, and diagnostics
• linting, tests, bundling, and code generation
• Linux-based CI as well as developer machines

5. Tune parallelism only after measuring

Running TypeScript 6.0 and 7.0 Side by Side

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

Should You Upgrade Now?

Test side by side if your project has custom compiler integrations, AST tooling, or a lint stack that still expects the TypeScript 6 API.

Wait for ecosystem confirmation if your daily workflow depends on embedded TypeScript support in Vue, Svelte, Astro, MDX, or Angular templates. TypeScript 7.1's planned API should unblock more of that ecosystem.

FAQ

What is new in TypeScript 7.0?

TypeScript 7.0 replaces the JavaScript-based compiler and language service with a native Go implementation. Its main improvements are much faster builds and editor feedback, multithreading, a rebuilt watch mode, lower memory use in published benchmarks, and an LSP-based editor experience.

Is TypeScript 7.0 really 10x faster?

Microsoft measured approximately 7.7x to 11.9x faster full builds across VS Code, Sentry, Bluesky, Playwright, and tldraw with the default four checker workers. Results vary by project, hardware, and configuration, so teams should benchmark their own workloads.

Is TypeScript 7.0 ready for production?

The TypeScript team describes 7.0 as production-ready after extensive automated testing and trials with large internal and external codebases. Production-ready does not mean every third-party tool is compatible, so verify the complete toolchain before rolling it out.

Does TypeScript 7.0 support typescript-eslint?

Can Vue, Svelte, Astro, MDX, and Angular use TypeScript 7.0?

Many of their specialized editor and template-checking workflows cannot use TypeScript 7.0 yet because they embed the TypeScript API. Some projects can still use TypeScript 7.0 for command-line checks while keeping TypeScript 6.0 for framework tooling.

What is the safest TypeScript 7.0 migration path?

Upgrade to TypeScript 6.0 first, resolve its new defaults and deprecations, measure existing build performance, and then test TypeScript 7.0 on a branch. Validate CI, editors, linting, framework tooling, declarations, watch mode, and project references before merging.

Final Take

TypeScript 7.0 makes the language toolchain feel dramatically lighter without asking developers to relearn TypeScript. Faster builds are valuable, but faster editor feedback may be the bigger everyday improvement: less waiting for diagnostics, navigation, completions, and watch rebuilds.

The upgrade is straightforward for many conventional TypeScript projects. The main decision is not whether native TypeScript is useful; it is whether every tool in your current stack is ready for a compiler that does not yet expose a programmatic API.