TypeScript 7.0 Is Fast. The Migration Is in Your tsconfig

On July 8 the TypeScript team shipped TypeScript 7.0, the first stable release of the native port written in Go. You still install it with npm install -D typescript and still run tsc, but the compiler now runs as native code with shared-memory multithreading, and the team says full builds are typically 8x to 12x faster. The speed is the easy part. The real work is in the defaults it inherits from 6.0 and in the programmatic API that isn't there yet.

What actually shipped#

A few rows from the benchmark table (run with the default four type-checkers):

• The VS Code codebase: 125.7s on TypeScript 6, 10.6s on 7 (11.9x).
• Sentry: 139.8s down to 15.7s (8.9x). Playwright: 12.8s down to 1.47s.
• Memory dropped too, by 6% to 26% depending on the project.

The language service is now built on the Language Server Protocol and can use multiple threads to serve simultaneous requests. Opening a file with an error in the VS Code repo went from about 17.5 seconds to under 1.3 seconds before the first error shows up. VS Code has a dedicated TypeScript 7 extension today, and the team says support will ship inside VS Code itself in the coming weeks.

The defaults are the migration#

TypeScript 7 adopts 6.0's new defaults and turns the flags and constructs deprecated in 6.0 into hard errors. The defaults that will bite:

• strict is true, module is esnext, and target defaults to the current stable ECMAScript version immediately before esnext.
• stableTypeOrdering is true and can't be turned off. noUncheckedSideEffectImports is on.
• types now defaults to []. The @types packages behind globals like process or describe must be listed; ["*"] restores the old behavior.
• rootDir now defaults to ./. If your tsconfig.json sits outside src, you need to set rootDir to keep the same output structure.

Both fixes are small:

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

These are now hard errors: target: es5, downlevelIteration, moduleResolution node/node10/classic, module amd/umd/systemjs/none, and baseUrl. You also can't set esModuleInterop or allowSyntheticDefaultImports to false. For baseUrl, the post says paths can be updated to be relative to the project root. The asserts keyword on imports must become with.

One change likely to break pre-commit hooks: tsc no longer accepts file paths when the current directory contains a tsconfig.json, unless you pass --ignoreConfig. Scripts that pass staged file paths to tsc need a look.

No API until 7.1#

TypeScript 7.0 ships without a programmatic API. The team expects 7.1 to ship a new, different API. Until then:

• typescript-eslint and other tools that need programmatic access to the compiler still rely on 6.0.
• Vue, MDX, Astro and Svelte projects will need to stay on 6.0 for now, because tools like Volar embed TypeScript into their own compilers and language services.
• Angular projects can use 7's tsc for fast project-wide errors on the command line and keep 6.0 for editor support.

The bridge is a new package, @typescript/typescript6, which provides a tsc6 binary and re-exports the 6.0 API. With npm aliases you can keep both:

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

Tools that import typescript through peer dependencies keep getting 6.0, and npx tsc runs 7.0. Before switching, grep for anything that imports typescript as a library: lint config, bundler loaders, codegen scripts. That list is your 7.1 waiting room.

CI settings to decide up front#

TypeScript 7 adds two experimental parallelism flags plus a single-threaded switch.

• --checkers sets the number of type-checking workers. The default is 4. The post suggests lowering it on machines with fewer cores and less memory, such as CI runners. It also warns that a different checker count can, in rare cases, surface order-dependent results, so pinning one value across environments is reasonable.
• --builders runs project-reference builds in parallel under --build. It multiplies with --checkers: 4 builders with 4 checkers means up to 16 type-checkers at once.
• --singleThreaded turns parallelism off entirely.

This matters more when several processes share a machine. I run multiple coding agents in parallel most days, and a type-check is a natural gate for their patches. A gate that takes seconds changes how often you can afford to run it. But several tsc runs on one machine, each with four checkers by default, add up in memory. I'd set --checkers explicitly for that setup instead of trusting the default.

What I'm doing about it#

My TypeScript work is mostly React, Next.js, React Native with Expo, and Node services on Fastify. The real question for me is which lint and build tools import the compiler. My plan, in order:

1. Get every project compiling cleanly on 6.0 with stableTypeOrdering on and no ignoreDeprecations. The team says practically any code that passes under those conditions should compile identically on 7.0.
2. Make types and rootDir explicit and replace baseUrl now, while still on 6.0, so the diff stays reviewable.
3. Move the CI type-check job to 7's tsc --noEmit with a pinned --checkers value, and keep 6.0 aliased for linting and anything that embeds the compiler.
4. Wait for 7.1 before touching toolchains that need the API.

The type-check job alone justifies the work. Just don't treat it as a version bump.