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.
The pipeline has been red on every run since at least ae0c34f. npm ci
installs dependencies but the Prisma client is generated into
src/generated/prisma, which is gitignored — so a fresh CI checkout has no
client and anything importing src/lib/db.ts fails with 'Cannot find package
@/generated/prisma/client' before a single assertion runs.
prisma generate reads only the schema, so it needs no database and no
secrets.
Worth noting why this went unnoticed for a dozen commits: a pipeline that
is always red carries no signal, so it stopped being read.
siddharthd