devnotes

TypeScript 7.0: what breaks, and how do you check before migrating?

TypeScript 7.0 shipped as the latest npm tag on 2026-07-08. The headline is tsgo, a native port of the compiler written in Go, and it's fast — 10x on most codebases. The part that trips teams up: tsc --noEmit (or tsgo --noEmit) passing tells you your source still type-checks, which was never the risk. The type system barely changed between 6 and 7; the implementation language did. The real breakage clusters in two places a type-check can't see, plus one place worth a look, not a panic.

Break #1: tsconfig flags that were deprecated, then removed

Options deprecated across the 5.x line are gone in 7.0. If ignoreDeprecations was your escape hatch for the warning, that flag is itself no longer accepted. Grep the whole tree, not just the root file — a monorepo usually inherits its tsconfig from a base file a dozen packages extend, so one stale option breaks every package at once:

grep -rnE '"(importsNotUsedAsValues|keyofStringsOnly|out|prepend|charset|ignoreDeprecations|noImplicitUseStrict)"' \
  --include=tsconfig*.json .

Worth a look too, though these are judgment calls rather than hard errors: "target": "es3" or "es5" (confirm you're at least ES2015), and "moduleResolution": "classic" (the pre-Node resolution mode — if you're still on it, that's a migration in itself).

Break #2: tooling that calls the Compiler API

This is the one that surprises people, because nothing in your code is wrong. Some tools don't run tsc — they import typescript and drive the Compiler API directly. The native port ships the compiler and language service first; the full programmatic API isn't in the initial 7.0 release. A package that reaches into the AST doesn't type-check wrong. It stops running.

Usual suspects: ts-morph and anything built on it, typedoc, type-aware typescript-eslint rules (the ones needing parserOptions.project), ts-patch / ttypescript, and ts-json-schema-generator. Find who in your tree touches the API:

npm ls typescript
grep -rnE "from ['\"]typescript['\"]|require\(['\"]typescript['\"]\)" \
  --include=*.ts --include=*.js --include=*.mjs scripts/ tools/

The fix is usually not "wait" — keep TypeScript 6.x installed side-by-side for the tools that need the API, and point 7.0 at your actual build and type-check.

Verify, don't panic: decorators and metadata

If you're on NestJS, TypeORM, MikroORM, or InversifyJS, you've probably seen the scary threads. The honest version: a clean TypeScript 6 build and a tsgo build should emit equivalent decorator metadata. This is a review step, not a fix step — build with 7.0, run your integration suite, boot the app. If DI resolves and your entities map, you're fine.

The order that matters

  1. Grep tsconfig for removed flags across the whole tree — cheapest, fails loudest, blocks everything else.
  2. npm ls typescript plus a grep for Compiler-API consumers — decide side-by-side-6.x vs. wait, per tool.
  3. tsgo --noEmit — now it means something, because you've cleared the noise it can't report on.
  4. Build and run the full test suite, especially for decorator/metadata frameworks.

--noEmit is step 3, not step 1. A CLI can run the first two checks across your repo and dependency tree in one pass, deterministically, no LLM key:

npx tsgo-ready

Notes from fernforge, which maintains tsgo-ready. Version facts checked against the live npm registry (typescript@7.0.2, latest, 2026-07-08).