TypeScript 7: What Breaks Is the API, Not Your Code

October 19, 2026 · 4 min read · #typescript #tooling

TypeScript 7 is the compiler rewritten in Go. I’d been running the preview (published as @typescript/native-preview, with a tsgo command) in my apps monorepo for a while, and in July 2026 it moved to typescript 7.0.2 proper. This blog’s repo is still on TypeScript 6.0.3, and it’s going to stay there for a bit.

The reason for the difference is the whole story. My code didn’t break in either repo. Tools did.

The part everyone talks about

It’s fast. Here’s tsc -p . on three of the apps, next to the TypeScript 5.9 copy that one dependency still installs (more on that below), median of three warm runs:

Six to nine times faster, and it found nothing the old compiler didn’t. For small projects, the difference is between noticing the type check and not noticing it. It changes how often you’re willing to run it: in a pre-commit hook, on every save, at the end of every agent turn.

What’s in the package now

Here’s the part that breaks things. For as long as TypeScript has existed, require("typescript") has given you the compiler itself: createProgram, the type checker, the language service that editors use. Hundreds of tools are built on it.

In 7, that package is a thin wrapper around a native binary, installed from a per-platform package like @typescript/typescript-darwin-arm64:

Copyconst ts = require("typescript"); // 7.0.2
Object.keys(ts); // [ 'version', 'versionMajorMinor' ]
typeof ts.createProgram; // 'undefined'

There’s a new API, under typescript/unstable/sync and typescript/unstable/async, and it talks to the Go binary over RPC. It’s unstable by name, and it’s a different shape, so a tool built on the old API doesn’t just keep working. The package also ships one command, tsc. There’s no tsserver.

So the question for any repo isn’t “does my code compile under 7?”. It’s “does anything in my toolchain import TypeScript?”

What that meant in practice

In the apps monorepo, the answer was “barely”:

• The rename. The preview’s command was tsgo, and 7 calls it tsc again. That touched 24 files: every package’s typecheck script, the CI config, and the docs and agent notes that mentioned tsgo. It’s a mechanical change, but a missed one fails loudly, which is what you want.
• Linting didn’t care. The linter is oxlint, which is native and has its own parser. One JavaScript plugin (for the i18n library) declares a peer range of TypeScript 5 or 6, so the install warns, but lint passes.
• One tool brings its own. react-doctor lists typescript as a regular dependency, pinned below 6. The package manager installs a private TypeScript 5.9.3 just for it. Nothing breaks; there are just two compilers on disk.

This blog is the other case. Its build runs astro check first, and astro check type-checks .astro files through Volar, which drives TypeScript’s language service from JavaScript. Its peer range is TypeScript 5 or 6. With 7 installed it doesn’t get far: current Astro checks the version first and stops with “astro check does not currently support TypeScript 7.0”. It couldn’t run anyway, since the typescript package it would load has no compiler API in 7.0.

So the blog pins typescript at 6.0.3, and the deps bump notes say so, so that nobody (me, or an agent doing a routine upgrade) “fixes” it. The way out is TypeScript 7.1, which adds content mappers: a hook that lets plain tsc check languages like .astro through a package (@astrojs/ts-content-mapper), with astro check set to be retired. Until 7.1 ships, the build stays on 6.

How to check your repo

Before switching, look for everything that depends on typescript, and read how:

Copygrep '"typescript"' bun.lock

• A peer dependency means the tool imports the compiler you installed. A range that stops at 6 is a real warning: expect it to break, unless the tool only uses TypeScript for types.
• A regular dependency means the tool brings its own copy. It keeps working; it just isn’t using yours.
• No entry at all, for tools like oxlint, esbuild or Vite, means they never touch the compiler. They strip types with their own parsers.

If you’re on TypeScript 6 and it prints deprecation warnings for your tsconfig, fix those first. 6 was the release that prepared for 7. One flag I would not turn off on the way is skipLibCheck. A faster compiler still shouldn’t spend its time type-checking .d.ts files.

Where I landed

• Apps repo: on 7. The only consumers were tsc itself and tools that either ignore it or bring their own.
• This blog: on 6. One tool needs the language service, and it’s the one the build depends on.
• Both: fine. Nothing in the code changed. The type errors are the same errors.

If your toolchain is mostly native (oxlint, Vite, esbuild, Bun), 7 is an easy win today. If it has something that reads your types from JavaScript (type-aware ESLint rules, framework checkers, doc generators), check that first, and don’t be embarrassed to wait.

Written by Zubin Khavarian