Additional option for skipping auto fixable rules

[okonet]

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.

[kaicataldo]

Thanks for the proposal. I have a few concerns:

1. Since ESLint's autofixer avoids fixing when it might change the execution behavior, rules that can autofix are not guaranteed to fix every problem. By skipping these rules, there will be times when CI is the first time some errors that must be fixed by a human will be displayed. This might work for your workflow, but I know I'd personally rather fix things locally before pushing them and having to wait for CI to catch things I need to fix.
2. Given that we have .eslintrc.js files, this can already be accomplished by using environment variables and a dynamically constructed configuration.

[okonet]

This might work for your workflow

That's why I propose a flag, not the default behavior

Given that we have .eslintrc.js files, this can already be accomplished by using environment variables and a dynamically constructed configuration.

I'd be interested in a solution that allow me doing this. AFAIK this is not possible at the moment.

[kaicataldo]

That's why I propose a flag, not the default behavior

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:

I honestly don't see any point of showing them if these errors are going to be fixed during pre-commit hook.

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'd be interested in a solution that allow me doing this. AFAIK this is not possible at the moment.

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.

[nzakas]

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 .eslintrc.js file with an environment variable that determines which rules to run. That was my first inclination when I read this proposal.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.