chore(deps-dev): upgrade ESLint to v10

[Wintus]

Summary

• Merges Dependabot PRs that bumped eslint to ^10.0.0 and @eslint/js to ^10.0.1
• Bumps typescript-eslint to ^8.56.0 (first release declaring eslint ^10 peer dep support)
• Adds overrides in package.json to forward the root eslint version to eslint-plugin-react-hooks, working around its outdated peer dep range (^3..^9) until a stable release adds ^10 support

Test plan

• npm run lint — ESLint 10 lints cleanly
• npm run build — TypeScript + Vite build passes
• npm test — all 71 Vitest tests pass

Co-Authored-By: Claude

[claude]

PR Review: ESLint v10 Upgrade

This is a clean, well-scoped dependency upgrade. Here is my analysis:

What the PR does

• Bumps eslint from ^9.39.2 → ^10.0.0
• Bumps @eslint/js from ^9.39.2 → ^10.0.1
• Bumps typescript-eslint from ^8.55.0 → ^8.56.0 (the first release that adds eslint ^10 to its peer dep range)
• Adds overrides in package.json to forward the hoisted eslint version to eslint-plugin-react-hooks

---

Correctness

The overrides workaround is correct and appropriate.
eslint-plugin-react-hooks@^7 declares a peer dep of eslint ^3 || ^4 || ^5 || ^6 || ^7 || ^8 || ^9, which excludes v10. Using npm overrides to forward $eslint is the standard workaround until the plugin ships a release that lists eslint ^10 explicitly. The approach is well-understood and widely used in the ecosystem.

typescript-eslint@8.56.0 is the correct minimum.
It is the first 8.x release declaring eslint ^10 peer support across the full set of packages (parser, plugin, utils, etc.). Choosing this version avoids spurious peer-dep warnings.

The lockfile is consistent. The nested @vitejs/plugin-react sub-tree keeps its own @babel/*@7.29.x copies while the root tree regresses to 7.28.6. This is expected npm deduplication behaviour when the two consumers have incompatible ranges, and does not introduce any runtime risk (Babel is dev-only).

---

Potential concerns

Node.js engine range tightens significantly.
ESLint 10 (and several of its internal deps – @eslint/config-array, espree, eslint-scope, minimatch@10, etc.) now requires ^20.19.0 || ^22.13.0 || >=24. If your CI or local dev toolchain runs Node 18 or early Node 20 (< 20.19), linting will break. Worth verifying .nvmrc / .node-version / the CI workflow's node-version matches these constraints.

@eslint/js now declares eslint ^10 as an optional peer dep.
This is intentional design in v10 (the package can be used standalone), but it means npm will no longer warn if eslint is missing. Not a bug, just something to be aware of if you ever refactor the config.

lodash.merge and several legacy packages are removed from the ESLint dependency tree. This is good (smaller install, fewer transitive deps), but if any other package in your tree pulls lodash.merge you would want to confirm it still resolves correctly. Given this is a pure devDep tree it is very unlikely to matter in production.

---

Test plan verification

The PR description confirms:

• npm run lint passes with ESLint 10
• npm run build passes
• All 71 Vitest tests pass

That is the right set of gates for a dev-tooling upgrade. No application source files changed, so no additional test coverage is needed.

---

Summary

The approach is sound. The overrides workaround is the correct short-term fix and should be removed once eslint-plugin-react-hooks ships ESLint 10 support (tracking: facebook/react#28313). Consider leaving a comment in package.json (or a TODO) to make the temporary nature of the override discoverable.

Verdict: Approve with one minor suggestion – verify the Node.js version in CI satisfies >=20.19.0 before merging.

[Wintus]

Verified with Node.js 22

https://github.com/Wintus/Wikipedia-Blame/actions/runs/22105343425/job/63886334710

node: v22.22.0
npm: 10.9.4
yarn: 1.22.22

the Node.js version in CI satisfies >=20.19.0