TypeScript 7 Shipped Without the API Your Tools Use

TypeScript 7.0 is out. It went GA on 8 July 2026, and the first stable build on npm is 7.0.2, published that day. The compiler is written in Go now, and Microsoft’s numbers for a full type-check are the ones everyone quotes: VS Code from 125.7 seconds to 10.6, Sentry from 139.8 to 15.7, Playwright from 12.8 to 1.47. Memory went down between 6% and 26% depending on the project.

That is not the interesting part any more. The interesting part is what happens when you actually run npm install -D typescript@7 in a repo that lints.

The gate is the compiler API, and it is not shipping until 7.1

From the release announcement: “TypeScript 7.0 does not ship with an API.” Not a reduced API, not an unstable one. The Go port does not expose the programmatic surface that typescript has exported for a decade, and the plan is for that to arrive in 7.1.

Anything that imports typescript and walks the AST or asks the checker a question is built on that surface. You can see the consequence in the package metadata rather than having to guess at it. As of 22 August 2026, typescript-eslint 8.67.0 declares its peer as typescript >=4.8.4 <6.1.0, and ts-jest 29.4.12 declares >=4.3 <7. Neither of them accepts TypeScript 7 at all. This is a loud failure at install time, not a subtle degradation later.

The announcement names the other side of it directly. Vue, MDX, Astro, and Svelte “will likely not yet be able” to run on TypeScript 7, and template type-checking of the kind Angular does is in the same position.

So the shape of the upgrade is not a version bump. It is running two compilers at once on purpose.

Installing both

typescript@7.0.2 provides a tsc binary. @typescript/typescript6, currently 6.0.2, provides tsc6 and the old API. I checked both bin fields on the registry rather than trusting the names.

The wrinkle is that tools do not ask for tsc6. They import the package literally named typescript, and typescript-eslint’s peer range means that name has to keep resolving to something 6.x. So the install uses npm aliases to put each compiler where the thing looking for it will find it:

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

Your type-check script runs the Go compiler; your linter resolves typescript and gets an API that exists. Check the announcement for the current form of this before you copy it, since the aliasing is the part most likely to be tidied up in a patch release.

If your repo has no type-aware lint rules, no jest transform, and no framework compiler, none of the above applies. Install typescript@7, run tsc --noEmit, and you are done in the time it takes to read this paragraph.

The real work is TypeScript 6, and it has nothing to do with Go

TypeScript 6.0 is the last release built on the JavaScript codebase, and it exists to move your tsconfig.json before the compiler changes underneath it. The defaults it flipped are the ones that will surface real errors in a codebase that has been coasting:

Setting	Was	Now in 6.0
strict	false	true
module	commonjs	esnext
target	es3/es5 era	es2025
types	every @types package	[]
rootDir	inferred	the tsconfig.json directory

Alongside those, 6.0 deprecates what 7.0 removes: target: es5 and --downlevelIteration, --moduleResolution classic and node10, the amd, umd, systemjs, and none module targets, --baseUrl, --outFile, and esModuleInterop: false.

A jump straight from 5.x to 7.0 eats all of that plus a new compiler in one commit, and when the build breaks you get to guess which half did it. Land on 6.0 first, clear what it complains about, and the Go switch becomes the small step it should be. That ordering is the whole migration plan; everything else is package names.

Turning the knobs, and the one that bites on small runners

The speedup has two sources. Native code is one. Shared-memory parallelism is the other, and it is the one you can tune:

• --checkers N sets the type-checking workers, default 4
• --builders N sets parallel project-reference builders under --build, which is what monorepos care about
• --singleThreaded turns all of it off

More checkers means more memory. A CI runner with two cores and a couple of gigabytes will not go faster because you asked for eight workers, and it may go from slow to killed by the OOM reaper, which reads as a flaky pipeline rather than as a memory setting. Benchmark on the runner, not on the laptop, and pin the numbers you tested.

In editors, TypeScript 7 arrives through a dedicated VS Code extension that takes over as the default once installed, with a “Disable TypeScript 7 Language Server” command in the palette when you want the old one back. Visual Studio picks it up from the workspace, and other LSP editors get the multithreaded language server without extra setup. Roll it out to a few people first. The language service is younger than the CLI, and an editor that stops offering completions costs more attention per day than a slow CI job.

Where this leaves you this week

If you are on 5.x, none of this is your next move. Upgrade to 6.0 and fix what it tells you.

If you are on 6.0 with a plain toolchain, install 7 and measure your own repo, because the published speedups came from codebases that spend a lot of time in the checker and a small project will not show you much.

If your CI gate includes type-aware lint, you are waiting for 7.1, and the useful thing to do in the meantime is the side-by-side install, so tsc --noEmit gets fast while the linter keeps its API. The version to watch is not TypeScript’s marketing page, it is the peer range in typescript-eslint’s package.json. The day that upper bound moves past 6.1 is the day this stops being a two-compiler repo.