ci(lint): bulk-suppressions baseline so new violations actually fail CI#212
Conversation
…wngrades The previous config demoted 8 rules to "warn" so the gate was green, but that also let NEW violations of those rules (no-explicit-any, the react-hooks v6 set, ...) through as warnings — defeating the gate. Restore every rule to its configured (error) severity and baseline the pre-existing violations in eslint-suppressions.json, so legacy debt is suppressed while any NEW violation fails CI. Promote react-hooks/exhaustive-deps to error (it's warn-by-default in eslint-config-next) so a new missing dependency gates too. Fix the broken `lint` script (Next 16 dropped `next lint`) to `eslint .`, and add `lint:baseline` to regenerate the suppressions file when the count legitimately changes.
|
Warning Review limit reached
More reviews will be available in 21 minutes and 25 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
What
Replaces the blanket warn-downgrade lint config with an ESLint bulk-suppressions baseline.
Why
The prior config demoted 8 rules to
warnto make the gate green on the pre-CI codebase — but that meant a newany, a newreact-hooks/set-state-in-effect, etc. also only warned, so the gate didn't actually block them. A baseline suppresses the existing violations while keeping every rule aterror, so new violations fail CI.How
eslint.config.mjs: removed the warn-downgrade block; all rules keep their configured (error) severity. Promotedreact-hooks/exhaustive-depsto error (warn-by-default) per the ask — it's the one most likely to fire on intentional patterns, so if it starts forcingeslint-disableon legitimate cases, downgrade that single rule back to warn.eslint-suppressions.json(new): baselines the 164 pre-existing violations (eslint --suppress-all).eslint .reads it automatically; CI'snpx eslint .is unchanged and now gates correctly.package.json:lintfixed (next lint→eslint .), addedlint:baselineto regenerate the suppressions file. Regenerate only when you intentionally change the violation count (e.g. a refactor), so a shifted count isn't a spurious CI failure.Verified
npm run lint(eslint .) → 0 errors (existing suppressed).const x: any = 1→eslintexits 1 withno-explicit-any error(new violations fail). Removed the probe.eslint --fix+lint:baseline.