You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(contents mostly stolen from my own issue in ESLint's repo eslint/eslint#16755)
What problem do you want to solve?
I would like there to be a system to suppress existing errors from being reported, so that I can enable a rule as "error" and be notified when new ones show up.
I believe that the way that this is done today in Biome and many other linters is through different imperfect means.
Using warnings
Warnings can help report errors without making required to be fixed.
A large problem with warnings is that as soon as there are more than a few warnings, you don't notice new ones showing up. A common practice I've seen quite often is to avoid warnings altogether, and to only use errors to avoid new problems creeping in. But that doesn't solve the problem of all the existing errors.
Also, users can too easily ignore the new errors, so in a way, the rule is enabled without being enforced when IMO the point of a linter is to enforce rules.
Using disable comments
One can use disable comments to temporarily suppress errors, by adding a comment like // biome-ignore lint: FIX THIS LATER <explanation>
Disable comments can be used to enable a rule as an error early, by adding them everywhere where an error is currently reported (and that is actually something that can be automated by some linters).
But disable comments have the tendency to be hard to distinguish from other disable comments created for reasons such as false positives or disagreements on the rule, especially when there is no enforced need to add a message on the comment. Meaning that once you decide to tackle the existing errors, they can be hard to detect (or to distinguish from ones that are disabled for good reasons).
They also "pollute" the codebase in a way that is quite visible, and makes users numb to the fact of using disable comments.
Ignoring parts of the project
It is also possible to simply disable the rule in each file that is currently reporting errors, either through manually configuring the rule in the configuration, or by adding a disable comment at the top of the file that disables the rule for the entire file.
This has multiple downsides:
While new errors are enforced in the other files, new errors can creep in the ignored files
If/when the errors in the ignored files get removed, the user has to remember to re-enable the rule on this file. Otherwise new errors can creep in also.
What do you think is the correct solution?
Here is some prior art on suppressing existing errors:
I am the author of the linter and blog post mentioned in the first bullet point. My recommendation would be to create a similar system to this one. It has worked really well so far for my users and I.
The blog post also describes the problems I've mentioned in greater detail than in this issue.
I am not willing to submit a PR nor a RFC as I am not using Biome and this would be a large endeavor, but I'd be happy to give advice and recommendations on how such a system should be put in place.
(PS: If you like this kind of proposal, I have plenty of other ideas on how to make Biome a better linter: https://www.youtube.com/watch?v=XjwJeHRa53A, happy to discuss them elsewhere)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
(contents mostly stolen from my own issue in ESLint's repo eslint/eslint#16755)
What problem do you want to solve?
I would like there to be a system to suppress existing errors from being reported, so that I can enable a rule as
"error"
and be notified when new ones show up.I believe that the way that this is done today in Biome and many other linters is through different imperfect means.
Using warnings
Warnings can help report errors without making required to be fixed.
A large problem with warnings is that as soon as there are more than a few warnings, you don't notice new ones showing up. A common practice I've seen quite often is to avoid warnings altogether, and to only use errors to avoid new problems creeping in. But that doesn't solve the problem of all the existing errors.
Also, users can too easily ignore the new errors, so in a way, the rule is enabled without being enforced when IMO the point of a linter is to enforce rules.
Using disable comments
One can use disable comments to temporarily suppress errors, by adding a comment like
// biome-ignore lint: FIX THIS LATER <explanation>
Disable comments can be used to enable a rule as an error early, by adding them everywhere where an error is currently reported (and that is actually something that can be automated by some linters).
But disable comments have the tendency to be hard to distinguish from other disable comments created for reasons such as false positives or disagreements on the rule, especially when there is no enforced need to add a message on the comment. Meaning that once you decide to tackle the existing errors, they can be hard to detect (or to distinguish from ones that are disabled for good reasons).
They also "pollute" the codebase in a way that is quite visible, and makes users numb to the fact of using disable comments.
Ignoring parts of the project
It is also possible to simply disable the rule in each file that is currently reporting errors, either through manually configuring the rule in the configuration, or by adding a disable comment at the top of the file that disables the rule for the entire file.
This has multiple downsides:
What do you think is the correct solution?
Here is some prior art on suppressing existing errors:
elm-review
's suppression system - described in this article https://jfmengels.net/stop-the-bleed/ember-template-lint
's TODO systemI am the author of the linter and blog post mentioned in the first bullet point. My recommendation would be to create a similar system to this one. It has worked really well so far for my users and I.
The blog post also describes the problems I've mentioned in greater detail than in this issue.
A similar discussion was opened in the Ruff linter: astral-sh/ruff#1149
I am not willing to submit a PR nor a RFC as I am not using Biome and this would be a large endeavor, but I'd be happy to give advice and recommendations on how such a system should be put in place.
(PS: If you like this kind of proposal, I have plenty of other ideas on how to make Biome a better linter: https://www.youtube.com/watch?v=XjwJeHRa53A, happy to discuss them elsewhere)
Beta Was this translation helpful? Give feedback.
All reactions