Measured 2026-09-12 - TypeScript 7.0.2
TypeScript 7 Compatibility Registry
Every row below is the exit code of a real tsc --noEmit run against a pinned package
version. Nothing here is inferred from a changelog, an issue thread, or a maintainer's intent.
Anything that failed was re-run on TypeScript 5.7.2 with the identical probe,
because "fails on 7" only means something next to "passed on 5.7".
- 18 compile clean
- 2 refuse to install alongside TypeScript 7
- 0 are TypeScript 7 regressions
- 1 failed on 5.7 as well
The one that will cost you an afternoon
typescript-eslint will not install next to TypeScript 7 at all. Not a type error,
not a deprecation warning: npm refuses to resolve the tree. Both the version pinned here and the
current release declare a peer range that stops below TypeScript 7, so the lint step of a project
that upgrades stops existing until that range moves. Both versions install cleanly against
TypeScript 5.7.2 in the same harness, which is how we know the package is
the constraint rather than the probe.
The second finding is not a package at all, and it accounts for more upgrade confusion than anything
in the table: TypeScript stopped loading @types/* automatically.
How each row was produced
One throwaway npm project per package. The package installed at the exact version shown, next to
TypeScript 7.0.2. One probe file importing it the way its own README does. Then
tsc --noEmit, and the compiler's exit code is the verdict.
{
"compilerOptions": {
"target": "es2022",
"module": "nodenext",
"moduleResolution": "nodenext",
"strict": true,
"noEmit": true,
"skipLibCheck": true,
"esModuleInterop": true,
"jsx": "react-jsx"
}
}
Why skipLibCheck is on. The first run of this harness had it off, which
produced five confident failures that were nothing of the sort: drizzle-orm was being judged on the
declaration file of an optional MySQL driver nobody had installed, and vitest on a symbol used inside
rollup. Real diagnostics, dishonest measurement. No project typechecks its dependencies' declaration
files, so neither does this.
What this does not tell you
- Nothing is executed. This is typechecking only, so runtime behaviour is untested.
- A probe touches the documented entry point, not every export. Deep API use may still break.
- A result applies to the exact version in the row and to no other.
Compiler behaviour changes
A library row answers "does this package still typecheck". These answer something else: did the
compiler change its mind about code you already wrote? Same probe, same tsconfig, three majors.
@types/* packages are no longer included automatically
You install @types/node, write process.env.PORT, and the compiler says it cannot find name process -- while the types sit right there in node_modules.
| TypeScript 5.7.2 | TypeScript 6.0.0-beta | TypeScript 7.0.2 |
|---|
| compiles | fails | fails |
Behaviour changes at TypeScript 6.0.0-beta.
probe.ts(1,38): error TS2591: Cannot find name 'process'. Do you need to install type definitions for node? Try `npm i --save-dev @types/node` and then add 'node' to the types field in your tsconfig.
The same file with types: ["node"] declared
The control for the row above. If this passes everywhere, the change is about automatic inclusion and nothing else, and the fix is one line of tsconfig.
| TypeScript 5.7.2 | TypeScript 6.0.0-beta | TypeScript 7.0.2 |
|---|
| compiles | compiles | compiles |
Same result on every version measured.
Read those two rows together and the whole thing collapses to one line of config. The types were in
node_modules the entire time; the compiler simply stopped picking them up on its own.
Declare "types": ["node"] and the identical file compiles on every version tested.
What the failures actually say
pino@9.6.0
Already failed on 5.7
probe.ts(2,13): error TS2349: This expression is not callable. Type 'typeof import("/private/node_modules/pino/pino")' has no call signatures.
Same probe on TypeScript 5.7.2: fail - so TypeScript 7 is not the cause, and upgrading will not fix it.
typescript-eslint@8.19.0
Refuses TypeScript 7 as a peer
Command failed: npm install --silent --no-audit --no-fund typescript@7.0.2 typescript-eslint@8.19.0 @types/node@22.10.2
Same probe on TypeScript 5.7.2: pass - so TypeScript 7 is the difference.
typescript-eslint@8.70.0
Refuses TypeScript 7 as a peer
Command failed: npm install --silent --no-audit --no-fund typescript@7.0.2 typescript-eslint@8.70.0 @types/node@22.10.2
Same probe on TypeScript 5.7.2: pass - so TypeScript 7 is the difference.
Who ran this
These measurements were run on 2026-09-12 by the
Coding Dunia editorial byline, which is a pen name and
says so on its own page. That matters more here than on an opinion piece, so it is worth being
exact about what the byline is and is not vouching for: not a credential, and not a promise that
a named individual stands behind the numbers. What it vouches for is that the harness in the
next section produced every figure on this page, that nobody typed a verdict by hand, and that
running it yourself is the intended way to check the claim rather than a courtesy.
A dataset is the one kind of page where that substitution actually works. You do not have to
trust the author, because you can re-run the measurement.
Reproducing this
The harness is in the repository that builds this site, and it is the only thing allowed to write a
row. There is no hand-authoring path, which is deliberate: the moment a matrix like this accepts a
"probably fine" it stops being evidence and becomes an opinion with a table around it. Run it and you
get your own numbers, on your own machine, with your own package versions.
Numbers go stale. Every row carries the date it was taken and the version it was taken against, so a
row that has aged out is visibly aged out rather than quietly wrong. If you need a verdict on a
package that is not here, the honest answer is that we have not measured it, and the table says so by
not containing it.
