Fix ESLint v10 RuleContext API removal (follow-up to #3972)#3979
Fix ESLint v10 RuleContext API removal (follow-up to #3972)#3979ledsun wants to merge 2 commits intojsx-eslint:masterfrom
Conversation
ljharb
left a comment
There was a problem hiding this comment.
we'll need regression tests - it might be as simple as adding eslint 10 to the GHA matrix.
f987ffa to
a7b967b
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3979 +/- ##
==========================================
+ Coverage 94.76% 97.26% +2.50%
==========================================
Files 134 137 +3
Lines 10165 10252 +87
Branches 3794 3833 +39
==========================================
+ Hits 9633 9972 +339
+ Misses 532 280 -252 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
6a95ab9 to
13c7805
Compare
|
@ledsun do you have time to address the failing checks. I'm looking at updating to eslint 10 and we're using the eslint-plugin-react |
…-react/eslint-plugin (#27011) ## Summary - Replace `eslint-plugin-react` (~7.37.5) with `@eslint-react/eslint-plugin` (~2.13.0) in `@fluidframework/eslint-config-fluid` to unblock ESLint 10 adoption - Use the `recommended-typescript` preset which auto-disables rules already handled by TypeScript - Keep `eslint-plugin-react-hooks` separately — it already has ESLint 10 support and provides React Compiler rules - Switch `print-configs` script from `tsx` to `jiti` to fix ESM-only package resolution ### Why `eslint-plugin-react` 7.37.5 is broken with ESLint 10 — it calls `context.getFilename()` which was removed. The upstream fix ([jsx-eslint/eslint-plugin-react#3979](jsx-eslint/eslint-plugin-react#3979)) has been blocked since February 2026. `@eslint-react` v2.13.0 supports ESLint 8/9/10, so this works now and won't block the ESLint 10 upgrade. ### Consumer updates Per-package eslint config and package.json updates (rule renames, removing redundant devDeps) will come in a follow-up PR stacked on this one. Resolves #27009
|
What's the status on this PR? Do we need to open another one? Seems we're just waiting for CI to pass? @ljharb ? |
|
Yes, it needs to be rebased and the test failures fixed. Please do NOT open a redundant PR; if you have changes you want added, comment with a branch or commit link, and I'll pull them in. |
|
I checked this from a local checkout of git rev-list --left-right --count origin/master...HEAD
# 0 2
|
@ljharb Is it still the case, i.e. blocked on |
Two upstream incompatibilities prevented lint from running: - eslint-config-next bundles typescript-eslint@8.48 whose @typescript-eslint/utils still does `class FlatESLint extends use_at_your_own_risk.FlatESLint` directly. ESLint 10 removed FlatESLint so this crashes on require. 8.59+ falls back to ESLint when FlatESLint is undefined. Forced via resolutions. - eslint-plugin-react's React-version auto-detection calls context.getFilename(), removed in ESLint 10. Workaround per vercel/next.js#89764: hardcode the React version in settings. Both workarounds are commented inline with the upstream tracking links so they can be removed once eslint-config-next ships with typescript-eslint >= 8.49 and eslint-plugin-react ships jsx-eslint/eslint-plugin-react#3979. With lint actually running, three pre-existing no-useless-assignment errors surfaced in DataTable.tsx and FeaturesClusterMarker.tsx (let foo = <default> followed by a fully-covering if/else chain). Fixed by dropping the dead initial assignment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
@ljharb Why not? It's not like this one is compatible with eslint 10 or something. When will it be fixed? |
This PR follows up on the feedback in the comments of #3972 and incorporates the requested changes.
I think this PR will fix #3977.