TypeScript 7 Is Here: The Native Compiler Era

TypeScript 7 is generally available. The headline is not a new utility type or a cleverer infer. It is that tsc is no longer written in TypeScript.

The compiler and language service have been ported to Go — the project that shipped as @typescript/native-preview and tsgo during the preview year. Microsoft’s numbers hold up: full type-checks on large codebases are typically 8× to 12× faster, memory is a bit lower, and the language server is substantially more stable.

This is the most consequential TypeScript release in years. It is also not a drop-in bump for every repo. Defaults got stricter, a long list of 6.0 deprecations is now a hard error, and the programmatic compiler API that half the ecosystem depends on does not ship until 7.1.

If your CI still burns several minutes type-checking a mid-sized app, that number is now a choice. Here is what actually changed, what breaks, and how to adopt it without stalling the rest of your toolchain.

Why a native port

TypeScript has always promised JavaScript that scales. The bottleneck stopped being the type system and started being the runtime that hosted it. The classic compiler ran on Node: single-threaded, GC-bound, and increasingly painful on monorepos that VS Code, Sentry, Slack, and the rest of us actually ship.

The 7.0 port was done as faithfully as possible. The team kept the structure and logic of the original codebase so results stay consistent between the two compilers. What you get is not a new type system. You get:

• Native code speed instead of a JS interpreter loop
• Shared-memory multithreading for parse, check, and emit
• A rewritten --watch mode based on a Go port of Parcel’s file watcher
• An LSP-first language server that can serve editor requests on multiple threads

Microsoft’s published full-build numbers (default --checkers 4) look like this:

Memory usually drops as well — on the order of 6–26% across those same trees. Opening a file with an error in the VS Code codebase went from about 17.5 seconds to first diagnostic down to under 1.3 seconds.

This is not esbuild, swc, or Biome. Those tools strip or transpile types. TypeScript 7 still type-checks. It just finally uses your cores to do it.

What a faster TypeScript feels like

A faster compiler sounds abstract until you map it onto a normal day:

1. Open the editor and wait for the project to load
2. Find-all-references, completions, and red squiggles as you type
3. Run tsc (or --watch) before you merge
4. Wait on CI for the same check at repo scale

Every one of those steps is shorter. Teams that already ran the preview reported the kind of numbers you notice without a stopwatch:

• Slack cut merge-queue time by about 40% and brought CI type-check from ~7.5 minutes to ~1.25 minutes. Local checking became feasible again.
• Canva went from ~58 seconds to first editor error down to ~4.8 seconds.
• Microsoft’s News Services team estimated 400 hours a month saved waiting on CI.

The new language server is not just faster. Microsoft reports over 80% fewer failing language-server commands and over 60% fewer crashes versus 6.0. For large workspaces that used to feel “unusable” in the editor, that is the actual product.

Install it

Same as every other release:

npm install -D typescript

That gives you the native tsc (npx tsc). Nightlies now live on the usual package again:

npm install -D typescript@next

The preview package @typescript/native-preview is no longer the path forward. If your editor has a TypeScript 7 / LSP toggle, turn it on. VS Code has a dedicated TypeScript 7 extension; Visual Studio can enable 7 from the workspace automatically.

The API gap (this is the real migration tax)

TypeScript 7.0 does not ship a stable programmatic API. Tools that import "typescript" and walk the checker — typescript-eslint, ts-jest, Volar, Angular’s template checker, webpack loaders, and similar — cannot move onto 7.0 yet. That API is the point of 7.1, expected on the usual 3–4 month cadence.

Until then, Microsoft’s sanctioned path is side-by-side: native 7 for tsc, TypeScript 6 for anything that needs the old Node API.

There is a compatibility package, @typescript/typescript6, with a tsc6 binary and the 6.0 API re-exported. Because many tools expect the package name typescript, npm aliases are the practical setup:

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

npx tsc then runs 7. ESLint, Jest, and the editor plugins that still talk to the 6.0 API keep working.

Practical split:

If you are on Angular, the common pattern is 7 for project-wide tsc and 6 for editor and template checking until the 7.1 API lands. In VS Code you can disable the TypeScript 7 language server and fall back to 6.0 when a plugin still requires it.

New defaults and hard errors

7.0 is meant to match TypeScript 6.0 type-checking and CLI behavior — provided you already compile cleanly on 6.0 with stableTypeOrdering on and without ignoreDeprecations. If you are still on 5.x, adopt 6.0 first. 7.0 turns 6.0’s deprecations into errors and ships 6.0’s new defaults.

Notable default changes:

• strict is true
• module defaults to esnext
• target defaults to the current stable ECMAScript version just below esnext
• noUncheckedSideEffectImports is true
• libReplacement is false
• stableTypeOrdering is true and cannot be turned off
• rootDir defaults to ./ — inner source trees must be set explicitly
• types defaults to [] (restore the old “load everything” behavior with ["*"])

The two that surprise people most are rootDir and types. If tsconfig.json sits above src, set rootDir or your emit layout changes:

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

If you relied on ambient @types packages being pulled in automatically, list them:

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

Flags and constructs that are now hard errors (no silent no-ops):

• target: es5
• downlevelIteration
• moduleResolution: node / node10 / classic — use nodenext or bundler
• module: amd | umd | systemjs | none
• baseUrl — make paths relative to the project root
• esModuleInterop / allowSyntheticDefaultImports cannot be false
• alwaysStrict cannot be false
• module inside namespace declarations
• asserts on imports — use with (import attributes)
• Passing file paths on the CLI when a tsconfig.json is in the current directory, unless you pass --ignoreConfig

If 6.0 already compiles your tree without deprecation escapes, 7.0 should type-check the same program. The work is almost entirely tsconfig reconciliation, not rewriting application types.

Small language-level change: Unicode in template literals

Template literal inference now treats Unicode code points, not UTF-16 code units. Emoji and other non-BMP characters infer as a single Head rather than a surrogate half:

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

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// previously: ["\ud83d", "\ude00abc"]

That matches for...of and [...str]. It will break type-level Length utilities that modeled UTF-16 on purpose. For everyone else, it is the behavior you already assumed.

JavaScript / JSDoc checking is also stricter and closer to .ts analysis (no Closure-style function(string): void, no @enum special case, typeof where a type is required, and so on). If you type-check a large JS tree, read the project CHANGES.md before you bump.

Parallelism you can tune

Parse and emit scale across files. Type-checking does not, at least not independently — too much shared global and dependency state, and ordering still matters for identical results.

7.0 runs a fixed number of checker workers (default 4). They may duplicate some work, but given the same inputs they always partition files the same way. Flags:

• --checkers N — type-check workers (try 8 on a fat workstation; drop toward 1 on small CI runners)
• --builders N — parallel project-reference builds under --build (helps monorepos; multiplicative with --checkers)
• --singleThreaded — cap everything to one thread for debugging or tiny machines

On the same published machine, --checkers 8 pushed vscode from 11.9× to 16.7× versus TypeScript 6. More checkers cost RAM. --checkers 4 --builders 4 can mean up to 16 checkers at once. Tune against your CI shape, not the blog table.

Watch mode is a different program

--watch is rebuilt on a Go port of @parcel/watcher, with small assembly shims so the TypeScript toolchain does not grow a C++ compiler dependency. Polling-only approaches were too expensive on large node_modules trees. The Parcel-based watcher is what VS Code has trusted for years; TypeScript 7 now owns that path in the CLI as well.

If --watch was the reason you avoided local tsc on a big repo, try it again.

A sane adoption order

1. Land on TypeScript 6.0 with deprecations resolved and stableTypeOrdering on. Do not jump 5.x → 7.0.
2. Fix tsconfig for the new defaults (rootDir, types, module / moduleResolution, strict).
3. Put native 7 on the CLI (tsc in CI and local check scripts). Measure wall-clock before and after.
4. Keep 6.0 aliased as typescript wherever ESLint, test runners, or framework plugins import the compiler API.
5. Editors: enable the TypeScript 7 LSP where you are on plain .ts / .tsx. Disable it for Vue / Svelte / Astro / MDX / Angular template workflows until 7.1.
6. Tune --checkers / --builders after the upgrade is green, not before.

You do not write Go. You still install via npm. Your tsconfig (minus removed options) is still the source of truth. The compiler is a prebuilt binary in the same package you have always depended on.

What 7.1 is for

The TypeScript team spent more than a year on this port. With 7.0 out, feature work returns: language ergonomics, more performance, and a new (different) API for the ecosystem. Releases should settle back to roughly every 3–4 months. 7.1 is the release that is supposed to let typescript-eslint, Volar, and the framework checkers leave the 6.0 compatibility package behind.

Until that lands, treat 7.0 as: native speed for tsc and the LSP, dual-stack for everything that still imports the compiler as a library.

Takeaway

TypeScript 7 keeps the type system you already know and replaces the engine that was holding it back. Full checks that used to be a coffee break are now a few seconds. The editor loads. CI shrinks. The cost is intentional strictness inherited from 6.0, plus one awkward quarter of dual compilers for API consumers.

If 6.0 already compiles your project, install 7, keep 6 beside it for plugins, and put the native tsc on the critical path. That is the whole migration for most TypeScript-first apps.

Welcome to the native era of the toolset.