ESLint version

v9.26.0

What problem do you want to solve?

I'm trying out the brilliant Bulk Suppression feature released in v9.24. It's really promising for legacy codebases, to suppress violations in legacy code while still enabling strict rules on new code. It also helps to keep eslint-disable directives only for false positives and for violations that I'm okay with not fixing.

The main downside I've seen so far is that there is no way to suppress warning-level violations — from the docs:

Only rules configured as "error" are suppressed. If a rule is enabled as "warn", ESLint will not suppress the violations.

What do you think is the correct solution?

I think the bulk suppression feature should simply work for all enabled rules, regardless of error/warn level.

Participation

• I am willing to submit a pull request for this change.

Additional comments

My linting config relies heavily on warnings as a way to reduce noise during development. For instance, when I declare a variable, I don't want to see a red squiggle before I've had time to write the code that makes use of it. Yellow squiggles are much less confronting and easier to "tune out".

But once I'm ready to commit/push my code, I want to make sure I'm not adding any new warnings to the codebase, so I always run ESLint with --max-warnings=0.

Being able to suppress warnings would be really beneficial for me for the same reason as being able to suppress errors: I currently have over 3000 warnings in the legacy codebase I'm working on; they are all legit, but fixing them is not worth the effort, and if I disable the rules, I don't get warned when I write new code 😢

In effect, I could pass the number of warnings that I want to suppress via --max-warnings, but it's not ideal since one could very well fix a warning in legacy code and introduce a new warning in new code within the same commit... I think the bulk suppression feature has the same limitation but only on a rule-by-rule basis at least.

Originally posted by @axelboc in #19613