Dependabot PR #193 (typescript 6.0.3 → 7.0.2) was closed on 2026-07-24 because the move is blocked upstream, not by anything in this repo. This issue records the finding so we pick it up when the blocker clears, rather than re-deriving it at the next bump.
Why it is blocked
TypeScript 7.0 ships no programmatic API at all. The typescript package's root export maps to ./lib/version.cjs, whose entire content exports two symbols:
node -e "console.log(Object.keys(require('typescript')))" # typescript@7.0.2
→ [ 'version', 'versionMajorMinor' ]
Microsoft states it plainly in the TS 7.0 announcement (2026-07-08): "While TypeScript 7.0 is here, it does not ship with an API."
That is the whole cause. @typescript-eslint/typescript-estree builds DEFAULT_EXTRA_FILE_EXTENSIONS from ts.Extension.Cjs at module top level (create-program/shared.ts:29), so ts.Extension is undefined and the module throws on load.
Our type-unaware config does not sidestep this. typescript-estree's project-less path is a plain in-process ts.createSourceFile(...) call (create-program/createSourceFile.ts:23, reached via createNoProgram()). No parser, no linting — with or without type information.
And there is no parser to port to. TS 7.0.2 does ship twelve unstable/* subpaths, but typescript/unstable/ast contains a scanner, node types, ~300 is* predicates, a visitor and a factory — and zero parse entry points. Filtering all 409 exports for /^parse|SourceFileFromText|transpile/i returns []. The createSourceFile in unstable/ast/factory is a node factory ((statements, endOfFileToken, text, fileName, path), arity 5), not a parser. The only route to an AST is unstable/sync, which loads a whole tsconfig project over IPC to the Go binary — it cannot take a source string, so it cannot serve a file-by-file linter parser.
Worth flagging because several third-party write-ups describe typescript/unstable/ast as "the standalone parser". It is not. Don't plan against that.
Upstream state (as of 2026-07-24)
| Artefact |
State |
| typescript-eslint#12518 "TypeScript 7.0.2 Support" |
closed not_planned, 38 min after filing (2026-07-08) |
| typescript-eslint#10940 |
the official tracker, open, label blocked by external API, locked since 2026-07-09 |
| typescript-eslint 8.65.0 (2026-07-20) |
added a legible "does not support TS 7.0" throw (#12529) — peer range unchanged |
| microsoft/typescript-go milestone "TypeScript 7.1" |
created 2026-07-15, due_on: null |
Maintainer position (bradzacher, 2026-07-09): "For now — there is nothing we can do to support tsgo / TSv7 … there is currently no stable JS API."
Microsoft expects 7.1 to ship "a new (and different) API" — a redesign, not a stabilisation of today's unstable/*. No date exists in any primary source; typescript@next is on 7.1.0-dev.* nightlies. Claims of a specific month circulating elsewhere are inference.
Not a blocker for us: eslint/eslint#15475 (async parsers, open since 2022, RFC closed unmerged 2023, not in ESLint 10) gates type-aware linting only. It would matter if we ever add typed linting.
The signal to watch
typescript-eslint is the only thing pinning us — verified across the whole lockfile: all eight @typescript-eslint/* packages peer typescript >=4.8.4 <6.1.0; ts-api-utils peers openly (>=4.8.4) and is uninvolved.
Machine-checkable, canary moves first:
npm view @typescript-eslint/typescript-estree@canary peerDependencies
# unblocked when the upper bound moves past <6.1.0
Human signal: #10940 closing as completed — or merely being unlocked, which is an early tell. Equivalently, watch SUPPORTED_TYPESCRIPT_VERSIONS in packages/typescript-estree/src/parseSettings/warnAboutTSVersion.ts on main, and the if (versionMajor >= 7) guard added by #12529 being removed.
Side effect worth knowing
The TypeScript 6 line ends at 6.0.3 — there is no 6.1; the line jumps straight to 7.0.x. With typescript: ^6.0.3 we sit at the end of the range and will receive no TypeScript updates at all until this resolves. Not a security concern (compiler, not runtime), but Dependabot will stay silent here, which is easy to misread as "nothing to do".
Option we deliberately did not take
TS 7's tsc already works on this codebase. Measured 2026-07-24, same app/tsconfig.json, explicit paths, both exit 0 with zero diagnostics:
| compiler |
result |
wall |
| TS 6.0.3 |
exit 0, no diagnostics |
9.97 s |
| TS 7.0.2 |
exit 0, no diagnostics |
4.80 s |
All twelve compilerOptions we use are supported; no type-checking behaviour differences surfaced. This repo is unusually well positioned for a split toolchain: no application code imports the typescript API (151 TS files, zero matches for from 'typescript'), and vite/vitest transform via esbuild/SWC — tsc is a pure CLI dependency (build, type-check).
The Microsoft-endorsed split, which typescript-eslint uses in its own repo (#12601):
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
(At least one user needed exact pins rather than caret ranges.)
Deliberately deferred. ~5 s of CI time does not justify a permanent double TypeScript install with two compiler versions checking the same source. When 7.1 lands the API, both problems resolve in one clean step. Revisit if type-check time becomes a real cost.
Done when
typescript is on 7.x with a single install, npm ci resolves without --force, and npm run lint / npm run build are green — i.e. the alias split above was never needed.
Dependabot PR #193 (typescript 6.0.3 → 7.0.2) was closed on 2026-07-24 because the move is blocked upstream, not by anything in this repo. This issue records the finding so we pick it up when the blocker clears, rather than re-deriving it at the next bump.
Why it is blocked
TypeScript 7.0 ships no programmatic API at all. The
typescriptpackage's root export maps to./lib/version.cjs, whose entire content exports two symbols:Microsoft states it plainly in the TS 7.0 announcement (2026-07-08): "While TypeScript 7.0 is here, it does not ship with an API."
That is the whole cause.
@typescript-eslint/typescript-estreebuildsDEFAULT_EXTRA_FILE_EXTENSIONSfromts.Extension.Cjsat module top level (create-program/shared.ts:29), sots.Extensionisundefinedand the module throws on load.Our type-unaware config does not sidestep this.
typescript-estree's project-less path is a plain in-processts.createSourceFile(...)call (create-program/createSourceFile.ts:23, reached viacreateNoProgram()). No parser, no linting — with or without type information.And there is no parser to port to. TS 7.0.2 does ship twelve
unstable/*subpaths, buttypescript/unstable/astcontains a scanner, node types, ~300is*predicates, a visitor and a factory — and zero parse entry points. Filtering all 409 exports for/^parse|SourceFileFromText|transpile/ireturns[]. ThecreateSourceFileinunstable/ast/factoryis a node factory ((statements, endOfFileToken, text, fileName, path), arity 5), not a parser. The only route to an AST isunstable/sync, which loads a whole tsconfig project over IPC to the Go binary — it cannot take a source string, so it cannot serve a file-by-file linter parser.Upstream state (as of 2026-07-24)
not_planned, 38 min after filing (2026-07-08)blocked by external API, locked since 2026-07-09due_on: nullMaintainer position (bradzacher, 2026-07-09): "For now — there is nothing we can do to support tsgo / TSv7 … there is currently no stable JS API."
Microsoft expects 7.1 to ship "a new (and different) API" — a redesign, not a stabilisation of today's
unstable/*. No date exists in any primary source;typescript@nextis on7.1.0-dev.*nightlies. Claims of a specific month circulating elsewhere are inference.Not a blocker for us: eslint/eslint#15475 (async parsers, open since 2022, RFC closed unmerged 2023, not in ESLint 10) gates type-aware linting only. It would matter if we ever add typed linting.
The signal to watch
typescript-eslintis the only thing pinning us — verified across the whole lockfile: all eight@typescript-eslint/*packages peertypescript >=4.8.4 <6.1.0;ts-api-utilspeers openly (>=4.8.4) and is uninvolved.Machine-checkable, canary moves first:
npm view @typescript-eslint/typescript-estree@canary peerDependencies # unblocked when the upper bound moves past <6.1.0Human signal: #10940 closing as completed — or merely being unlocked, which is an early tell. Equivalently, watch
SUPPORTED_TYPESCRIPT_VERSIONSinpackages/typescript-estree/src/parseSettings/warnAboutTSVersion.tsonmain, and theif (versionMajor >= 7)guard added by #12529 being removed.Side effect worth knowing
The TypeScript 6 line ends at 6.0.3 — there is no 6.1; the line jumps straight to 7.0.x. With
typescript: ^6.0.3we sit at the end of the range and will receive no TypeScript updates at all until this resolves. Not a security concern (compiler, not runtime), but Dependabot will stay silent here, which is easy to misread as "nothing to do".Option we deliberately did not take
TS 7's
tscalready works on this codebase. Measured 2026-07-24, sameapp/tsconfig.json, explicit paths, both exit 0 with zero diagnostics:All twelve compilerOptions we use are supported; no type-checking behaviour differences surfaced. This repo is unusually well positioned for a split toolchain: no application code imports the typescript API (151 TS files, zero matches for
from 'typescript'), and vite/vitest transform via esbuild/SWC —tscis a pure CLI dependency (build,type-check).The Microsoft-endorsed split, which typescript-eslint uses in its own repo (#12601):
(At least one user needed exact pins rather than caret ranges.)
Deliberately deferred. ~5 s of CI time does not justify a permanent double TypeScript install with two compiler versions checking the same source. When 7.1 lands the API, both problems resolve in one clean step. Revisit if type-check time becomes a real cost.
Done when
typescriptis on 7.x with a single install,npm ciresolves without--force, andnpm run lint/npm run buildare green — i.e. the alias split above was never needed.