chore(deps-dev): Bump the npm group across 1 directory with 2 updates

[dependabot]

Bumps the npm group with 2 updates in the / directory: @types/node and typescript.

Updates @types/node from 26.1.1 to 26.1.2

Commits

• See full diff in compare view

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 pnpm run lint: the already-installed @typescript-eslint/eslint-plugin@8.65.0 throws typescript-eslint does not support TS 7.0. at module load time whenever it detects a TS major version ≥ 7, aborting ESLint before any files are linted (exit code 2). Since lint is invoked by precommit:check and all, this will also fail CI; the fix is to hold the typescript bump until typescript-eslint adds TS 7 support, or upgrade typescript-eslint to a version that supports it.

Extended reasoning...

This PR bumps typescript from ^6.0.3 to ^7.0.2 (package.json:61) but leaves @typescript-eslint/eslint-plugin and @typescript-eslint/parser pinned at ^8.64.0 (resolving to 8.65.0 in the lockfile). That eslint-plugin version contains a hard guard at module load time in dist/index.js that parses ts.versionMajorMinor and does:

const [versionMajor] = ts.versionMajorMinor.split(".").map(Number);
if (versionMajor >= 7) {
  console.error([...]);
  throw new Error("typescript-eslint does not support TS 7.0.");
}

This is distinct from (and stricter than) the soft warning in @typescript-eslint/typescript-estree's warnAboutTSVersion.js, which only warns for TS versions below its supported range. The eslint-plugin's own load-time guard throws unconditionally once it sees TS major version 7, regardless of how new/well-supported that version otherwise is.

Code path: package.json's lint script (eslint src tests "scripts/**/*.ts") loads @typescript-eslint/eslint-plugin, which resolves typescript to whatever satisfies its peer dependency — now 7.0.2 per the updated pnpm-lock.yaml. The guard fires during plugin initialization, before ESLint processes a single file, so the whole command aborts with exit code 2 and zero files linted.

Why nothing else catches this first: typecheck and test are unaffected because they use @typescript/native (already pinned to typescript@^7.0.2 prior to this PR) rather than the typescript package the eslint-plugin resolves against. So a green typecheck/test run gives no signal that lint is now broken.

Step-by-step proof (empirically verified by three independent verifiers, all reproducing the same result):

1. Install the lockfile as modified by this PR: typescript resolves to 7.0.2, @typescript-eslint/eslint-plugin resolves to 8.65.0(...)(typescript@7.0.2).
2. Run pnpm run lint (equivalently node node_modules/eslint/bin/eslint.js src tests "scripts/**/*.ts").
3. ESLint fails immediately with exit code 2 and the message: typescript-eslint does not support TS 7.0. — confirmed to originate from node_modules/@typescript-eslint/eslint-plugin/dist/index.js lines ~43-50.
4. Zero files are linted; the process aborts before reaching any source file.
5. Since precommit:check runs pnpm run lint && pnpm run typecheck && ... and all runs pnpm run typecheck && pnpm run lint && ..., both of those composite scripts also fail, and CI (which presumably invokes one of these) will fail on this PR.

Impact: Merging as-is breaks local lint/precommit:check/all and will fail CI outright — a concrete, reproducible failure rather than a stylistic or descriptive mismatch.

Fix options: hold the typescript devDependency bump at ^6.x until @typescript-eslint ships TS 7 support, or bump @typescript-eslint/eslint-plugin/@typescript-eslint/parser to a version that supports TS 7.0 (if/when available) in the same PR.

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.