#113 Fix Failing Checks On Dependabot Eslint 9→10 Bump

[b-at-neu]

Closes #113

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
aplio	Ready	Preview, Comment	Jun 21, 2026 11:23am

[b-at-neu]

Code Review

Critical

• package-lock.json — The lockfile was not regenerated after package.json was updated. It still resolves eslint to 9.39.4 and eslint-config-next to 16.2.4. When CI runs npm ci, it installs ESLint 9 — not ESLint 10 — so the upgrade never takes effect. Fix: run npm install locally and commit the updated package-lock.json.

All other dimensions clean — actions v4, node-version pin, and version bumps in package.json are correctly implemented.

---

Reviewed against plan in issue #113

[b-at-neu]

Code Review

Critical

• .github/workflows/linting-check.yml — run-linting-check is failing in CI. The plan's root cause analysis identified two candidates that this PR does not fully resolve: (1) eslint-plugin-react@7.37.5, eslint-plugin-jsx-a11y@6.10.2, and eslint-plugin-import@2.32.0 are nested inside eslint-config-next/node_modules and still declare peer deps capped at ESLint ^9 — even under eslint-config-next@16.2.7, so ESLint 10 may still surface peer dep warnings that cause --max-warnings=0 to fail; (2) node-version: '20' resolves to whatever Node 20 patch the runner image ships — if it resolves below 20.19.0, ESLint 10's engine requirement (^20.19.0 || ^22.13.0 || >=24) is unmet and ESLint will refuse to run. The PR cannot be merged until this CI check is green. Pull the job logs to confirm the exact error and fix accordingly (pin node-version: '20.19' or higher, and/or check whether a --legacy-peer-deps flag in CI or an overrides in package.json is needed for the plugin peer deps).

Low

• .github/workflows/linting-check.yml:14 — node-version: '20' only pins the major version. Pinning to '20.19' (minimum minor satisfying ESLint 10's engine requirement) would make the constraint explicit and guard against future runner image regressions. Current ubuntu-latest ships Node ≥20.19 today, but this is fragile.
• package.json:68 — eslint-config-next is pinned to an exact version "16.2.7" without a caret. This matches the pre-existing 16.2.4 exact-pin pattern, so it is consistent, but worth noting that patch updates won't be picked up automatically.

Nit

• .github/workflows/ — all three workflow files now duplicate the same checkout@v4 / setup-node@v4 / node-version: '20' block. Extracting a reusable workflow would prevent future version drift between the three files (e.g. the ESLint 10 node-version fix would need to land in only one place).

---

Reviewed against plan in issue #113

[b-at-neu]

Revision Summary

Fixed

• .github/workflows/linting-check.yml:14, .github/workflows/prettier-check.yml:14, .github/workflows/tsc-check.yml:14 — pinned node-version from '20' to '20.19' in all three CI workflows. ESLint 10 declares engines: { node: "^20.19.0 || ^22.13.0 || >=24" } in its package manifest; node-version: '20' on ubuntu-latest can resolve to any Node 20 patch below 20.19.0, causing ESLint to refuse to run. This addresses the Low finding and guards against future runner image regressions.

Upstream blocker — Critical CI failure cannot be resolved in this PR

The run-linting-check CI failure has a root cause that is beyond this PR's scope to fix:

eslint-plugin-react@7.37.5 is fundamentally incompatible with ESLint 10.

eslint-config-next@16.2.7 bundles eslint-plugin-react@7.37.5 in its own node_modules. That version of the plugin calls context.getFilename() (a method removed in ESLint 10; it was deprecated in v9 and replaced by context.physicalFilename). Running eslint . --max-warnings=0 with ESLint 10 crashes immediately with:

TypeError: Error while loading rule 'react/display-name': contextOrFilename.getFilename is not a function

The eslint-plugin-react maintainer confirmed this explicitly in jsx-eslint/eslint-plugin-react#4018: "This plugin is explicitly not yet compatible with eslint 10, so it's an error to try to use them together. Stick with v9 for now."

The fix PR (jsx-eslint/eslint-plugin-react#3979) is still open as of June 2026 and not yet merged. There is no released version of eslint-plugin-react that supports ESLint 10. npm overrides cannot help because the issue is a runtime API removal, not a version range declaration — no published version of the package has the fix.

Preexisting issues — suggested for future tickets

• Issue Fix failing checks on dependabot eslint 9→10 bump (PR #105) #113 / PR Bump eslint from 9.39.4 to 10.4.1 #105 remain blocked upstream. The ESLint 9->10 migration for this project cannot complete until eslint-plugin-react releases a version that replaces context.getFilename() with context.physicalFilename, and eslint-config-next ships a version that bundles that fixed plugin. Suggested future ticket: "Upgrade to ESLint 10 once eslint-plugin-react ships ESLint 10 compat" — watch Fix ESLint v10 RuleContext API removal (follow-up to #3972) jsx-eslint/eslint-plugin-react#3979 for merge and a subsequent eslint-config-next bump.

• Nit: workflow duplication. All three CI workflow files share the same checkout@v4 / setup-node@v4 / node-version block. Extracting to a reusable workflow would prevent future version drift. Low priority; suggested as a separate tooling cleanup ticket.

[b-at-neu]

Closing: the ESLint 9→10 upgrade is blocked upstream. eslint-plugin-react@7.37.5 (bundled inside eslint-config-next) calls context.getFilename(), which was removed in ESLint 10. The fix PR (jsx-eslint/eslint-plugin-react#3979) is still open and unmerged — no released version of the plugin supports ESLint 10 yet. Reopening once eslint-plugin-react ships a compatible release and eslint-config-next bundles it.