An easy way to disable --fix rules

[fgarcia]

The version of ESLint you are using
4.2.0

The problem you want to solve

When I integrate ESLint with my code editor I get a huge number of errors. I do not want to spend time fixing spacing errors, empty spaces after the end of line, double empty lines...

I would like to reduce the error noise by showing only the ones requiring my attention. Later after saving a file or right before a commit, I would use ESLint with --fix

Ideally I could have a ruleset for "while editing" and an extended one for "pre-commit fix". However if I use a shared config like AirBnB or StandardJS I must disable/enable one by one the rules that can be auto fixed

Your take on the correct solution to problem

Introduce an option to disable rules that can be fixed, like --ignore-fixable or --ignore-fix

[ljharb]

I'm confused; if they're errors by the config you're using, they're errors - you need to spend time fixing them.

If you don't want the airbnb config's un-fixable errors, don't use the airbnb config.

[not-an-aardvark]

Closing as a duplicate of #7549, duplicate of #8018, and duplicate of #8935

[fgarcia]

@ljharb I want to spend time fixing errors that requires me to fix them. Unsused variable? Yes I must fix that. However I do want solid spacing rules too: single colons, etc... but if my code editor starts sending error signals and encourage me stop my work to fix details that can be automatically fixed, I would rather disable ESLint in my editor.

@not-an-aardvark All three issues you mention are "disable --fix per rule". My proposal is "disable all rules that support --fix", specially from the command line

1. If I am using a code editor, I want to see only the errors that do require my attention
2. If I am going to commit a file. I want ESLint to fix/beautify my code

It is quite hard setting up ESLint and separate beauty rule sets from problem detection. If I want ESLint to focus on the later, I have to create my own ruleset from scratch. If I use an existing one, I also need lots of configuration to reduce the error noise.

Using ESLint as a problem detection tool requires a lot of work. Using ESLint as a code beautifier is quite easy. I do believe my request, and not the quoted issues, would encourage the former case with just a single command line option

[not-an-aardvark]

Could this be addressed within the editor integration by simply not displaying fixable issues? It seems like this isn't a problem with ESLint itself -- it's providing all the information, it's just that your editor isn't presenting it to you in a useful way.

[fgarcia]

From my point of view a linting tool has two goals: problem detection and beautification. I would expect an easy way to separate both objectives within the linting tool, not within each editor.

I really want the benefits of problem detection in my editor, but I avoid the integration with ESLint because I do not want a tool that forces me to beautify my own code. Specially if the tool itself can do it

[fgarcia]

By the way. My issue request is about running ESLint and not displaying fixable issues. That is exactly what I want. How could I tell my editor which ones are the fixable issues to ignore?

[ilyavolodin]

@fgarcia Couldn't this be fixed by having two separate configs? .eslintrc file can only enable non-fixable errors, secondary config (let's say .fixeslintrc) would inherit from .eslintrc and include all fixable rules that you care about. That way, editor will only pick up .eslintrc file and if you want to autofix from the command line, then you can always run ESLint with --config flag, and pass it .fixeslintrc file.

[not-an-aardvark]

How could I tell my editor which ones are the fixable issues to ignore?

Your editor should already have access to this information. If it's using the API, problems with a fix property are fixable.