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
Additional option for skipping auto fixable rules #10957
Comments
Thanks for the proposal. I have a few concerns:
|
That's why I propose a flag, not the default behavior
I'd be interested in a solution that allow me doing this. AFAIK this is not possible at the moment. |
I would still be hesitant to introduce a new feature that feels broken on release. I think where I'm having trouble with the current proposal is in the following assumption:
ESLint doesn't guarantee all instances of errors will be fixed in a rule that has an autofixer. By adding a feature flag like this we're agreeing to supporting and maintaining this new feature, and I think most people would see it and assume that all instances of errors in rules with autofixers are fixable, which isn't the case.
I believe this would be feasible using ESLint's Node.js API to check if rules are fixable or not and filtering those that are fixable out of the config's list. @nzakas @not-an-aardvark @platinumazure Do you mind giving this a look, since this is tangentially related to the proposal and discussions we've had for this proposal? Let's see what the rest of the team has to say. |
While I do agree that we need more control over when rules are and are not fixed (as in #10855), I'm not sure this proposal makes sense for most users. As @kaicataldo points out, there is no guarantee that a fixable rule will apply any fixes to the output at all, so there is no clear distinction between a rule that will and will not apply fixes during precommit. I also agree that the best way to trigger different behavior in different environments is to use a |
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
The version of ESLint you are using.
v5.6.0
The problem you want to solve.
When ESLint is used with tools like lint-staged on pre-commit, it makes sense to not lint against auto-fixable rules during development process. This especially concerned about IDE integrations since such rules are generating a fair amount of noise in the IDEs. I honestly don't see any point of showing them if these errors are going to be fixed during pre-commit hook.
At the same, I'd like these rules to be enabled during the normal run, for example, on CI.
Your take on the correct solution to problem.
I think the simplest solution would be to add an additional flag (
--skip-fixable-rules
) to the CLI that would exclude autofixable rules automatically.I could implement an alternative CLI runner myself using the API but there is at least one bug that prevents me from doing so.
Additionally, since the config has to be resolved per file, this means I would end up with something very similar to the current CLI runner.
The text was updated successfully, but these errors were encountered: