The Lint job has never once passed — 7 runs, 7 failures — on 48 errors that are
all in apps/v4, and apps/v4 is a VENDORED upstream mirror. Every flagged file
arrives from a sync commit ("feat: sync upstream shadcn/ui"): hooks/use-layout.tsx
and examples/{base,radix}/** from b74fc5759, components/command-menu.tsx from
fd9d7843f. The examples/base and examples/radix copies are byte-identical to each
other, so a third of the list is the same file counted twice.
eslint-config-next 16 turns the React Compiler rules on. Upstream shadcn does not
satisfy them, so we were linting somebody else's code against a stricter config
than they use. Patching it would fork ~20 vendored files from upstream and have
to be redone at the next sync, to quiet advisories in a demo app.
This is not a new exemption, it is finishing an existing one. The config already
turned off react-hooks/incompatible-library and react-hooks/purity for precisely
this reason, and TWO files already carried inline
`// eslint-disable-next-line react-hooks/set-state-in-effect`. The same rule was
being suppressed already — just inconsistently, in 2 of the 20+ places it fires.
Those two inline directives are now redundant and are removed here; eslint
flagged them itself once the rule went off.
set-state-in-effect "Calling setState synchronously within an effect can
trigger cascading renders" 42 of 48
refs "Cannot access refs during render" 6 of 48
Scope is exactly apps/v4: that config governs nothing else. Our own source —
app/, pkgs/, packages/ — lints under its own config, which does NOT disable any
react-hooks rule, and still passes. Nothing we author is exempted.
If these rules should hold for vendored code too, the fix belongs upstream in
shadcn/ui rather than as a local fork of 20 files.
Verified with the workspace eslint (9.39.4, the version CI installs — a stray
npx picks up 10.5.0 and crashes eslint-plugin-react before linting anything):
`turbo run lint` is 2 successful / 2 total, 0 errors, 0 warnings.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>