-
-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
📎 CLI flag in linter to write ignores for existing violations #4007
Comments
I personally don't have any problems with the As for code pointers, I don't have perfect context on how suppressions are implemented. But from just a quick look around, I don't think it will be that difficult. You'll probably want to look at:
|
For the implementation of the feature, I would start simple, and use the default behaviour message of the suppression actions. Then, we can follow up with the customisation of the suppression reason. The business logic must be implemented at Workspace level, in the function You might want to start with biome/crates/biome_service/src/file_handlers/javascript.rs Lines 661 to 688 in 76a4f1a
The analyser infrastructure always provides a suppression action, if implemented. For example, I doubt that We will have to update enum ChosenAction {
/// Chose the code fix
Default,
/// Chose the suppression, with an optional reason
Suppression(Option<String>)
} |
@ematipico, do you think it makes sense for me to add a pub enum FixFileMode {
SafeFixes,
SafeAndUnsafeFixes,
ApplySuppressions // New
} My thinking is that |
FWIW I'd love to be able to apply all fixes (just safe or also unsafe) and suppress the remainder in one command - |
@allanlewis, I'm thinking of this feature as a migration tool rather than a consistent part of your workflow. When that's the case, it seems being able to run both at the same time seems to lose a good bit of value. Also, we're talking about saving milliseconds when we're talking about running one Biome command instead of two... However, I'm also being selfish. I can see how I can write this if they're mutually exclusive more easily than if they're not, which is why I asked. 😄 If we do think they really need to be ran at the same time, I can sort it out (eventually). |
Description
As described in this discussion and in Discord, it would be great to have an option to write in ignores for existing rule violations.
I stumbled upon the need for this feature while working on migrating a large codebase to Biome. There are rules I'd like to activate that have hundreds and thousands of violations, but I can't reasonably fix them all in one PR. I can use some creative override patterning to get it done, but an easier way would be to set ignores for them and follow up with PRs to fix those ignores. There are likely other use cases for this feature, as well.
I will be starting work on this feature momentarily, having received prior blessings from @ematipico and @Conaclos at that Discord pointer.
Open questions:
biome lint . --write-suppressions
while I work but can name it whatever the crowd prefers.// biome-ignore the/rule/name: <explanation>
, so I'd like to allow for an explanation withbiome lint . --write-suppressions="TODO: Fix Biome migration ignores."
, where my string would become the<explanation>
. If not provided, a default explanation will be provided (or we could just let it be<explanation>
?). Any thoughts here on what to provide for a default? And does that API sound good?The text was updated successfully, but these errors were encountered: