Linter: disabling code fixes for rule emitting warnings

[Conaclos]

The problem

Some code fixes, such as noUnusedVariables can be annoying when someone is programming. However, it is valuable before committing or pushing at a repository. However, some users like also to apply the code fixes on every save.

For example, some users would like removing unused imports on save.
Others dislike the idea.

I think we can satisfy the two wishes with the following proposal.

Proposal

I propose to disable code fixes for rules set on warning level.
A user could still opt in either changing the level to "error", or using the option --error-on-warnings.

This solves the previous issue:

• a user that wants removes unused imports could set the concerned rule at "error", or use --error-on-warnings.
• a user that wants only applies code fixes before committing / merging could use --error-on-warning.
• other users have nothing to change

Notes

Also I think we shoudl be able to set a rule level to warning for a recommended rule.
We could then recommend noUnusedVariables keeping its level at warn by default.

[ematipico]

There are users that want to downgrade a rule to a warning because they want them to distinguish from syntax errors or type errors, and still get the code fix , and use --error-on-warning to fail on CI.

Our users from react-grid-table use this strategy.

I don't mind the proposal, but I fear that if we decide to change the behaviour of the tool to satisfy some use cases, we risk penalizing others without even knowing.

Wouldn't it be safer to keep the existing behaviour, and craft new options to enable the behaviour to the one you proposed?

[Conaclos]

For example, yes. Are there other linters that behave like this, or allow to change to this kin of behaviour?

I don't think so.

I thought about another approach: we could introduce a new group "ci". All rules of this group are enabled (recommended) when running biome ci and disabled (not recommended) when running biome check/biome lint. This group could include the following rules: noUnusedVariables, noUnusedImports, noConsoleLog, noDebugger, noUselessBlockStatements, ... (every rule which could be too picky when writing code).

I am not fond of introducing a new special category. However, we have already nursery and actually it makes sense.
This could also free the correctness group of non-recommended rules. I pretty like the idea that a category induces the recommended flag of a rule (what Clippy is doing). Accessibility, correctness, performance, and suspicious categories could have only recommended rules.

[Conaclos]

@ematipico what do you think about my last thought?

[ematipico]

This is something users can do today with different configuration files, if they need.

Unfortunately I still fail to see a common denominator for the initial proposal. If a rule is pedantic, users can turn it off, suppress it or make it a warning. And in the future we'll have CLI too, which will probably solve your problem.

The second proposal is more subtle, changing the diagnostic level based on commands is unexpected, and that's not what the ci command is meant for. Users will end up using check because ci doesn't respect the configuration.

[Conaclos]

Do you think it makes sense of creating the ci category (we could use another name). This allows users turning on/off these rules just by turning on/off the category.

[ematipico]

Are you thinking about something like a pedantic group? If so, then it makes sense.

But groups and rules should not be turned on/off based on the environment. It could make our life very difficult: documentation, teaching users, predictability, user experience, developer experience, etc.

[Conaclos]

Closing in favor of #2882