chore(deps-dev): Bump typescript from 6.0.3 to 7.0.2 in the npm group across 1 directory

[dependabot]

Bumps the npm group with 1 update in the / directory: typescript.

Updates typescript from 6.0.3 to 7.0.2

Commits

• See full diff in compare view

Maintainer changes

This version was pushed to npm by microsoft1es, a new releaser for typescript since your current version.

[claude]

🔴 Bumping typescript to ^7.0.2 breaks the production build: @vercel/ncc@0.44.1's bundled ts-loader calls TypeScript's internal findConfigFile/getConfigFile helpers, which crash on TS 7's new module shape ('TypeError: Cannot read properties of undefined (reading fileExists)'). Running 'pnpm run build' exits 1 with no dist output, so 'build', 'check-dist', and 'all' all fail, which will break CI.

Extended reasoning...

The bug: typescript@7.0.2 is not a newer release of the classic TypeScript compiler — it is the native Go port ("tsgo") repackaged under the same npm name. Its default module export (resolved via package.json's exports map to ./lib/version.cjs) only exposes { version, versionMajorMinor }. The full classic compiler API (ts.sys, ts.findConfigFile, createProgram, etc.) that virtually every TS tool built against for the last decade is simply gone from the main entry point; only a new ./unstable/* surface remains.

Code path that triggers it: The build script in package.json (line ~13) runs ncc build src/main.ts -o dist .... @vercel/ncc@0.44.1 bundles its own ts-loader, which does require('typescript') and then calls the classic helpers findConfigFile → getConfigFile to locate/parse tsconfig.json, reading .fileExists off what it expects to be a ts.sys-like host object. Since typescript@7.0.2's export no longer provides that object, the property access throws TypeError: Cannot read properties of undefined (reading 'fileExists'), and ncc's build process dies with exit code 1 and no dist/ output.

Why nothing in the PR prevents this: The PR only touches package.json/pnpm-lock.yaml to bump the typescript devDependency (and separately adds @typescript/native pointing at the same typescript@^7.0.2 package, used only by the typecheck script). Nothing in the diff updates or pins @vercel/ncc, and no released version of @vercel/ncc (as of this bump) supports TS 7's new shape — so the moment typescript resolves to 7.0.2 for the root project, ncc's ts-loader is guaranteed to crash on every build.

Impact: This is a total, deterministic build failure, not an edge case. check-dist (pnpm run build && git diff --exit-code -- dist) and all (which ends in pnpm run build) both depend on build and fail the same way. Since this repository is a GitHub Action whose committed dist/ is produced via ncc, any CI job that runs build, check-dist, or all will fail on this PR, and merging would leave the repo unable to regenerate its shipped dist/ bundle at all.

Step-by-step proof (reproduced independently by three verifiers and confirmed here):

1. Install with this PR's lockfile (typescript@7.0.2, @vercel/ncc@0.44.1 unchanged).
2. Run pnpm run build (equivalently node node_modules/@vercel/ncc/dist/ncc/cli.js build src/main.ts -o dist --source-map).
3. ncc logs ncc: Using typescript@7.0.2 (local user-provided), then its bundled ts-loader calls require('typescript') and invokes findConfigFile/getConfigFile against the resolved module.
4. Because typescript@7.0.2's resolved entry (./lib/version.cjs) only exports { version, versionMajorMinor }, the host object ts-loader expects (with a .fileExists method) is undefined.
5. The property access throws TypeError: Cannot read properties of undefined (reading 'fileExists') inside ts-loader.js.cache.js, ncc reports Error: Module build failed, and the process exits with code 1. No dist/ directory is produced.

How to fix: Do not merge this bump as-is for the root typescript devDependency used by ncc/build tooling. Either hold typescript (the classic compiler, used by ncc/ts-loader and other tooling) at a 6.x-compatible version while introducing @typescript-eslint/@typescript/native separately for the type-checking-only path, or wait for @vercel/ncc (and other tools in the chain) to ship TS 7 support before bumping the shared typescript package that ncc's build step resolves against.

[claude]

🔴 Bumping typescript to ^7.0.2 breaks lint: @typescript-eslint/eslint-plugin@8.65.0 and @typescript-eslint/parser@8.65.0 only support typescript >=4.8.4 <6.1.0, and eslint-plugin has a hard guard that throws at module load time on TS 7.0. Running pnpm lint fails with exit code 2, which breaks lint, lint:fix, precommit:check, and all, and will fail CI.

Extended reasoning...

The bug: package.json bumps the regular typescript devDependency from 6.0.3 to ^7.0.2. pnpm-lock.yaml then re-resolves @typescript-eslint/eslint-plugin@8.65.0 and @typescript-eslint/parser@8.65.0 (and their transitive deps typescript-estree, type-utils, utils, project-service, tsconfig-utils, ts-api-utils) against typescript@7.0.2. All of those @typescript-eslint packages declare peerDependencies.typescript: ">=4.8.4 <6.1.0" — 7.0.2 is well outside that range.

Why this isn't just a soft peer warning: Normally an out-of-range peer dependency under pnpm with relaxed peer checking just prints a warning and installs anyway. But @typescript-eslint/eslint-plugin ships an explicit hard version guard that runs at module load time (not lazily, not only when linting a file) and throws when it detects TS major version 7. This means the plugin can never even be loaded, let alone used, once typescript@7.0.2 is installed.

The code path: pnpm run lint → eslint src tests "scripts/**/*.ts" → ESLint loads the flat config → the flat config requires @typescript-eslint/eslint-plugin → eslint-plugin/dist/index.js executes its TS-version guard on import → throws Error: typescript-eslint does not support TS 7.0. Please see ... to run typescript-eslint using the TS 6 API. See also github.com/typescript-eslint/typescript-eslint/issues/10940. This is a deterministic crash, not conditional misbehavior.

Proof (concrete repro reported by multiple independent verifiers who actually ran the command against the installed lockfile):

1. Install with this PR's lockfile → node_modules/typescript resolves to 7.0.2, and node_modules/@typescript-eslint/parser/package.json / typescript-estree/package.json both still declare peerDependencies.typescript: ">=4.8.4 <6.1.0" (confirmed directly, and typescript-estree's own SUPPORTED_TYPESCRIPT_VERSIONS constant literally is that string).
2. Run pnpm run lint (or node node_modules/eslint/bin/eslint.js src).
3. Process exits with code 2 and prints: Error: typescript-eslint does not support TS 7.0. thrown from @typescript-eslint/eslint-plugin/dist/index.js:50:11.
4. Because lint fails, everything that chains through it also fails: lint:fix, precommit:check (lint && typecheck && format:check && check:schema), and all (typecheck && lint && test && check:schema && build). CI's workflow runs lint, so the PR as-is fails CI outright.

Why the project's own setup doesn't protect against this: The repo deliberately keeps two separate TypeScript installs — @typescript/native (npm:typescript@^7.0.2, the new Go-ported compiler) is used only for the typecheck script via node node_modules/@typescript/native/bin/tsc, while the plain typescript package was intentionally kept on the 6.x line so that @typescript-eslint's type-aware linting keeps working. This PR (an automated Dependabot bump grouped as "npm group") bumps the wrong one — the plain typescript devDependency — collapsing that separation and breaking the tooling it was designed to protect. typecheck itself still works since it never touches the plain typescript package.

Fix: Either pin typescript back to the 6.x line (e.g. ^6.0.3 or whatever satisfies @typescript-eslint's peer range) and let @typescript/native continue to own the 7.x TS engine for typecheck, or hold off on this bump until @typescript-eslint ships support for TS 7 (tracked upstream in typescript-eslint/typescript-eslint#10940).