To baseline existing violations, record the current findings for a rule in a committed file and enforce the rule only on new findings. Then shrink the file over time. ESLint's bulk suppressions feature works exactly this way and is a clear model, even if you use other tools.
The problem baselines solve
Turning a new rule on as an error is hard when the code base already has many violations and the rule has no automatic fix. ESLint's documentation notes that unless a rule is enabled early in a project, it becomes harder and harder to enable as the code grows, because existing violations must be resolved first and new ones may appear in the meantime.
How ESLint does it
According to the ESLint documentation:
- After enabling a rule as "error", the suppress-all flag records all current violations. Running it with the fix flag is recommended, so auto-fixable violations are fixed and not suppressed.
- A suppress-rule flag does the same for a named rule.
- Suppressions are stored in a file called eslint-suppressions.json in the project root. The docs say to commit it so every developer shares the same baseline.
- Only rules configured as "error" are suppressed. A rule set to "warn" is not.
- When you fix a violation, ESLint exits non-zero and reports unused suppressions, and a prune-suppressions flag removes them.
That last behavior is the important design choice. A baseline that cannot only grow is a debt ledger, not a loophole.
Steps for any tool
- Fix what is auto-fixable first.
- Generate the baseline in a single commit, so it is easy to review and to find later.
- Store it in the repository, not on a developer machine.
- Make the build fail on anything not in the baseline.
- Make the build also notice stale entries, so fixes shrink the file.
- Publish the count and review it monthly.
Baseline versus inline suppression
| Baseline file | Inline comment | |
|---|---|---|
| Best for | Many legacy findings | One deliberate exception |
| Carries a reason | Usually not | Should |
| Shrinks automatically | If the tool prunes | Only when someone edits |
| Visible in review | One large generated diff | Each line, in context |
Use both: a baseline for history, and inline comments with reasons for new, deliberate exceptions.
Risks to manage
- Baseline as hiding place. Someone can regenerate the file to silence a real new finding. Require review on changes to the baseline file, for example through a code owners entry.
- Never shrinks. Set a target, such as the count must fall each quarter.
- Wrong severity. Because warn rules are not suppressed in ESLint, enable the rule as error first, then baseline.
Quick check
Should the baseline file be committed?
Yes. ESLint's docs say to commit its suppressions file so all developers share it. A local only baseline gives different results on different machines.
Does a baseline mean the old findings are accepted?
No. It means they are deferred. Track the count and burn it down, and keep real risks out of the baseline.
Safeguard's scanning covers dependencies and SBOMs, and its reachability analysis helps show which findings your code can actually call. You can run a free scan on a repository.
Sources
Last reviewed: 19 October 2026.
