chore(deps): bump eslint from 9.39.4 to 10.8.0 - #114
Conversation
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
85b476c to
fec831e
Compare
suhailsalim
left a comment
suhailsalim
left a comment
There was a problem hiding this comment.
Review — eslint 9.39.4 → 10.8.0
Blocked upstream — do not merge. This isn't a config problem on our side; the ESLint 10 support simply does not exist yet in eslint-plugin-react.
The blocker, precisely
Latest published eslint-plugin-react is 7.37.5, and its declared peer range is:
eslint: ^3 || ^4 || ^5 || ^6 || ^7 || ^8 || ^9.7
ESLint 10 is not in that list, and no release supports it. The install succeeded anyway only because .npmrc sets strict-peer-dependencies=false, so the conflict never surfaced at install time — it surfaced at rule-load time instead:
TypeError: Error while loading rule 'react/display-name':
contextOrFilename.getFilename is not a function
That is ESLint 10 having removed the deprecated context compatibility shim the plugin still calls.
The reported failure understates the blast radius
CI failed at the Lint step with Tasks: 1 successful, 4 total — Turbo bailed after @akasecurity/ui-kit#lint, so Typecheck, Test and Build never ran. Everything downstream is unmeasured:
- All three consumers of
@akasecurity/eslint-config/reactbreak identically, not justui-kit—packages/ui-kit,packages/dashboard-ui, andweb-uiall pullconfigs.recommended.rules(which includesreact/display-name) throughpackages/eslint-config/src/react.js:17. packages/eslint-config/test/effective-config.test.jsresolves every realeslint.config.mjsthrough theESLintclass programmatically. It exercises the same rule-loading path, so it should fail too — the Test step just never got there.
So the fix list is one item long, but the green-CI bar is further away than a single failing package suggests.
The rest of the toolchain is already ESLint 10-ready
Checked every plugin in packages/eslint-config:
| Package | Latest | eslint peer range | ESLint 10? |
|---|---|---|---|
eslint-plugin-react |
7.37.5 | ^3 || … || ^9.7 |
no |
eslint-plugin-react-hooks |
7.1.1 | … || ^9.0.0 || ^10.0.0 |
yes |
typescript-eslint |
8.65.0 | ^8.57.0 || ^9.0.0 || ^10.0.0 |
yes |
eslint-plugin-n |
18.2.2 | >=8.57.1 |
yes |
eslint-config-prettier |
10.1.8 | >=7.0.0 |
yes |
eslint-plugin-simple-import-sort |
14.0.0 | >=5.0.0 |
yes |
eslint-plugin-react is the single gate.
Pre-existing drift this bump exposes (worth fixing either way)
packages/eslint-config/package.json already depends on @eslint/js@^10.0.1 — whose own peer is eslint: ^10.0.0 — while eslint is pinned ^9.0.0. The lockfile records it as @eslint/js@10.0.1(eslint@9.39.4(jiti@2.7.0)). main today is running an ESLint 10 rule package against an ESLint 9 core, tolerated silently by strict-peer-dependencies=false.
That is exactly the class of mismatch that produced the crash above, just one that happens not to have bitten yet. Independent of this PR, it's worth either pinning @eslint/js back to ^9 or making peer conflicts visible in CI.
Two ways forward
- Wait for
eslint-plugin-reactto ship ESLint 10 support, then re-run this bump. - Drop
eslint-plugin-reactand keepeslint-plugin-react-hooks(already 10-compatible). The repo's entire use of it isconfigs.recommended.rulesplus two immediate overrides (react/react-in-jsx-scope: off,react/prop-types: off) inpackages/eslint-config/src/react.js. With React 19 and TypeScript strict mode, most of that recommended set is either redundant with the compiler or aimed at pre-JSX-transform / PropTypes-era code. This unblocks ESLint 10 now and reduces the toolchain surface.
Option 2 is the one I'd take, but it's a deliberate lint-policy change rather than something to fold into a Dependabot bump — better as its own PR that this one then rebases onto.
| "@akasecurity/eslint-config": "workspace:*", | ||
| "@types/react": "^19.2.17", | ||
| "eslint": "^9.0.0", | ||
| "eslint": "^10.8.0", |
There was a problem hiding this comment.
This is where CI died:
TypeError: Error while loading rule "react/display-name":
contextOrFilename.getFilename is not a function
Nothing about it is specific to ui-kit — Turbo just reached this package first and bailed (Tasks: 1 successful, 4 total). The rule comes from eslint-plugin-react's configs.recommended.rules, spread in at packages/eslint-config/src/react.js:17, so all three consumers of the react config fail the same way: packages/ui-kit, packages/dashboard-ui, and web-ui.
Because Lint is the first CI step, Typecheck / Test / Build never ran on this branch at all — the real failure count is unmeasured.
| }, | ||
| "peerDependencies": { | ||
| "eslint": "^9.0.0", | ||
| "eslint": "^10.8.0", |
There was a problem hiding this comment.
This narrows the peer range rather than widening it: ^9.0.0 → ^10.8.0 drops ESLint 9 entirely, forcing a big-bang switch. ^9.0.0 || ^10.0.0 would let the migration land package-by-package instead.
Minor in practice, since this package is private: true and only consumed in-workspace — but it's the difference between an incremental path and an all-or-nothing one, and right now the all-or-nothing path is closed by eslint-plugin-react (peer range stops at ^9.7, latest 7.37.5).
| }, | ||
| "devDependencies": { | ||
| "eslint": "^9.0.0", | ||
| "eslint": "^10.8.0", |
There was a problem hiding this comment.
Related drift that already exists on main and is worth fixing regardless of what happens to this PR: the dependencies block above pins @eslint/js@^10.0.1, whose own peer is eslint: ^10.0.0, while eslint here is ^9.0.0. The lockfile records it as @eslint/js@10.0.1(eslint@9.39.4(jiti@2.7.0)).
So an ESLint 10 rule package is already running against an ESLint 9 core, silently — .npmrc sets strict-peer-dependencies=false, so pnpm never complained. That is the same class of mismatch that produced this PR's crash, just one that has not bitten yet. Either pin @eslint/js back to ^9, or make peer conflicts visible in CI.
| "@types/react": "^19.2.17", | ||
| "@types/react-dom": "^19.2.3", | ||
| "eslint": "^9.0.0", | ||
| "eslint": "^10.8.0", |
There was a problem hiding this comment.
web-ui consumes the same react config (web-ui/eslint.config.mjs spreads ...react), so it breaks identically — Turbo simply never reached it.
There is a second failure waiting further down too: packages/eslint-config/test/effective-config.test.js resolves every real eslint.config.mjs through the ESLint class programmatically, which walks the same rule-loading path. It should fail on ESLint 10 as well, but the Test step never ran.
Follow-up: exact root cause, and a one-line unblockTraced the crash to its source rather than inferring it — the picture is better than my review above implied. The removed API is const filename = typeof contextOrFilename === 'string'
? contextOrFilename
: contextOrFilename.getFilename();The parameter name
That guard is the interesting part. We opt into it ourselves at settings: {
react: { version: 'detect' },
},So pinning the version to a literal bypasses settings: {
react: { version: '19.2' },
},We already pin React exactly (
Important caveat: that unblocks, it does not make the plugin supportedjsx-eslint/eslint-plugin-react#3977 "ESLint v10 compatibility" is still open (filed 2026-02-07, 43 comments), with the maintainer stating plainly that the plugin is not compatible with ESLint 10 and shouldn't be used with it until the peer range is updated. Fix PRs #3972 and #3979 are both unmerged — #3979 was blocked on an So the version pin is a workaround against a plugin whose maintainer says don't run it here. Fine as a deliberate, documented stopgap; not something to merge silently inside a Dependabot bump. One correction to my table above
Clearing the blocker is necessary but not sufficientESLint 10 carries changes that will surface new work once linting runs at all — none of which this branch has measured, since it died at the first package:
There's an official codemod for the mechanical parts: Recommendation unchanged — hold this PR. But the sequencing is clearer now: land the |
8d43c6e to
85690b6
Compare
Bumps [eslint](https://github.com/eslint/eslint) from 9.39.4 to 10.8.0. - [Release notes](https://github.com/eslint/eslint/releases) - [Commits](eslint/eslint@v9.39.4...v10.8.0) --- updated-dependencies: - dependency-name: eslint dependency-version: 10.8.0 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
85690b6 to
5461766
Compare
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
2 participants
Bumps eslint from 9.39.4 to 10.8.0.
Release notes
Sourced from eslint's releases.
... (truncated)
Commits
749dfed10.8.04bd0d75Build: changelog update for 10.8.04fbf46dtest: pinwebpackversion to 5.108.4 (#21137)6ddf858docs: fix broken Specify Parser Options anchor link (#21106)784dfbedocs: Clarifyno-eq-nulldescription (#21120)6b8d2f7fix: escape reserved characters in rule id inhtmlformatter (#21129)2d063e2chore: update HTTP URLs to HTTPS in JSDoc and comments (#21101)eccbe7btest: add error locations tono-class-assign(#21123)2fee9bbfeat: exportConfigObjectfromeslint/config(#21082)e7d1e43ci: bump actions/setup-go from 6 to 7 (#21118)