CI ran lint with continue-on-error because 23 errors predated it. All are
fixed, so the flag is gone and a typecheck step is added beside it — nothing
else in CI compiles the test files, so a type error in a fixture could only
ever be found on a developer's machine.
Real fixes, no blanket disables and no suppressions:
- react-hooks/set-state-in-effect (6): each was "reset or seed state when an
input changes", so each becomes a state adjustment during render behind a
previous-value guard — the documented React pattern for it. Two were also
latent bugs. transactions/page.tsx depended on `others`, rebuilt by .filter()
every render, so the effect already ran every render, one commit late.
shared/page.tsx depended on the `tagIds` array identity, so the row window
was reset more often than "changing any filter" claims — including after
"Show more", the one interaction it must not undo; the key now joins by
value. csv-import-modal reads localStorage once at mount, which is a lazy
useState initializer, not an effect (SSR-guarded, though the modal is
mounted from client state and never prerenders).
- react-hooks/static-components (3): SortIcon was declared inside SharedPage,
making it a new component type on every render. Hoisted to module scope with
the sort state passed as props.
- @typescript-eslint/no-explicit-any (9): the dynamically imported route
handlers in two integration tests. Typed as their real signatures with one
`as unknown as NextRequest` cast at the fixture boundary, so the call sites
and response bodies get checked instead of opted out.
- react/no-unescaped-entities (5): exact-equivalent entities (', "),
so no rendered text changes.
Also fixes the one pre-existing tsc error (unit/order-ingestion.test.ts:511):
`options` is optional, and `?? 0` keeps the assertion failing on an absent
list rather than silencing it with a non-null bang.
9 warnings remain (no-unused-vars, exhaustive-deps). eslint exits 0 on
warnings, so lint blocks on errors only — deliberately, since none of the
remaining warnings should stop a push.
Selecting a rule now shows the transactions it would alter, so a subset can be
ticked and applied rather than trusting a bulk run. The apply step takes explicit
transaction ids (the existing bulk apply_rule path), so what you tick is exactly
what changes - a rule whose conditions are too broad cannot reach further than
the preview showed.
Matches are split into 'would change' and 'already correct'. A merchant
normalisation rule matching 400 rows where 380 already hold the right value is 20
changes and 380 rows of noise; only the 20 are listed.
Preview is offered for every rule including manual_only quick actions, which
previously had no way to see their reach at all. A rule with no conditions
matches every transaction - that is how apply already behaves, so the preview
reports it prominently rather than hiding it.
Applies still snapshot to rule_apply_runs, so they remain revertable.
siddharthd