Clear 127 lint findings and gate lint in CI

[fylorn]

What

pnpm lint goes from 127 problems (90 errors) to 0, and is now one of the steps the Frontend Build job runs.

It had reported those 127 since the first commit: eslint-plugin-react-hooks@7 was a dependency from day one and lint was never gated. A check with no gate only moves one direction — which is the actual finding here, and why the last commit adds the gate rather than just the fixes.

Every change is verified against the CI steps: pnpm install --frozen-lockfile, check:i18n (1386 keys), lint, 96 tests, pnpm build.

Real defects fixed

• dashboard.tsx built its provider list with live?.providers ?? [], which allocates a fresh array on every render while live is null. Both useMemos below it were keyed on that array, so neither had ever memoised anything.
• A rethrow that dropped its cause. A dead initialiser. A try/catch that only rethrew. An empty catch with nothing saying why. Write-only state that cost a render per load.
• Date.now() read during render in two countdown labels. They take a ticking clock from a new useNow now, so they actually count down instead of freezing until something else re-renders.

State that was pretending to be a ref

use-wizard-state held its session id, resume flag and template slug in refs assigned during render and read back later. That is the one thing the compiler cannot reason about: it may discard a render pass, and a ref written only in render then holds a value that was never committed. One lazy useState now. Same fix for two ref mirrors assigned during render rather than in an effect.

Effects that were doing state alignment

Resetting a form when a dialog opens, clearing a list when its id changes, dropping to page 1 when a search term changes — all of it ran after paint. The stale pair was on screen for a frame, and in the pagination case long enough to fire a request for page 4 of a two-page result and race its response. These use a new useResetOnChange, which is React's documented adjust-during-render pattern with the comparison written once instead of fifteen times.

Three reads that should have been initialisers: the dismissed-state of the getting-started card, the mobile breakpoint, the OAuth callback banner. Each rendered its wrong value once and corrected after mount — the mobile one meant every phone got a frame of desktop layout.

Dependency arrays (23)

Eleven were a missing t. The rest were a missing loader, and those could not simply be added: every one of those loaders was a plain arrow function, so listing it hands the effect a new identity each render and spins. Seventeen loaders are useCallback-wrapped now with the dependencies ESLint computes, which is what makes the effects' own arrays honest rather than a [] with a suppression on top.

That removed nine suppressions and, with them, nine React Compiler warnings — it refuses to optimise a component that disables a rule, so each eslint-disable exhaustive-deps was costing a second finding somewhere else.

What keeps a suppression, and why it is written down once

Eighteen sites, with the reason in a new "Data fetching" section of web/README.md rather than repeated eighteen times. Loads here are hand-rolled — a useCallback that fetches and sets state, plus an effect that calls it — and set-state-in-effect fires on the shape. Hoisting the spinner flag out to render time silences the rule but splits "start a load" across two places and leaves every other caller of the loader holding half of it.

Nine further sites are a different claim: useEffect(() => { load(); }, [load]) where load is async and its first statement is the await. Every setState inside runs in the continuation — never synchronously with the effect, never a cascading render. The rule's cross-function analysis does not model await.

Both categories disappear with a data-fetching layer (TanStack Query or equivalent), which owns the loading flag and the cache and removes the effect. That is deliberate work, not something to fold into a lint pass. The note says so, and says not to add suppressions of this rule for any other reason — every other finding it reports is real, and the tree is now clean of them.

Config decisions, both commented

• A leading underscore already meant "deliberately unused" in this codebase. no-unused-vars knows that now instead of reporting the convention as five defects.
• Two rules are off for src/components/ui/, which is shadcn output: its sidebar writes document.cookie inside a useCallback, and its files ship a component next to its variants. Both are upstream's implementation, and the next shadcn add would put them back.

🤖 Generated with Claude Code