Follow-up from #8608's eslint 10 migration.
eslint-plugin-react-hooks 5 → 7 (forced by the eslint 10 security chain) introduced four React-Compiler-era rules that flag 24 pre-existing files in apps/loopover-ui:
react-hooks/set-state-in-effect (24 errors — the bulk)
react-hooks/purity (1)
react-hooks/refs (1)
react-hooks/static-components (1)
apps/loopover-miner-ui is already clean (it adopted v7 earlier).
These are demoted to warn in apps/loopover-ui/eslint.config.ts with a comment citing #8608 — fixing setState-in-effect patterns is real UI refactoring with behaviour risk, not something to smuggle into a dependency bump. Every rule that existed in v5 stays at error.
The work
Fix the flagged patterns file-by-file (mostly converting synchronous setState inside effects to derived state, event handlers, or useSyncExternalStore where appropriate), then delete the four "warn" overrides so the rules return to error via the recommended preset.
The warning output of npm run ui:lint is the live worklist.
Follow-up from #8608's eslint 10 migration.
eslint-plugin-react-hooks5 → 7 (forced by the eslint 10 security chain) introduced four React-Compiler-era rules that flag 24 pre-existing files inapps/loopover-ui:react-hooks/set-state-in-effect(24 errors — the bulk)react-hooks/purity(1)react-hooks/refs(1)react-hooks/static-components(1)apps/loopover-miner-uiis already clean (it adopted v7 earlier).These are demoted to
warninapps/loopover-ui/eslint.config.tswith a comment citing #8608 — fixing setState-in-effect patterns is real UI refactoring with behaviour risk, not something to smuggle into a dependency bump. Every rule that existed in v5 stays aterror.The work
Fix the flagged patterns file-by-file (mostly converting synchronous
setStateinside effects to derived state, event handlers, oruseSyncExternalStorewhere appropriate), then delete the four"warn"overrides so the rules return toerrorvia the recommended preset.The warning output of
npm run ui:lintis the live worklist.