New CLI Option: --select-rule

[customcommander]

Hi guys,

We have started to introduce ESLint on a couple of fairly large code bases and the rules we have established generate thousands of errors and warnings :-)

I tend to fix on a rule by rule basis but I find it a bit cumbersome sometimes as I need to copy the rule from the eslintrc.json file, wrap it in a json-like string and paste it to the command line. e.g.:

eslint --rule '{new-cap: [2, {"capIsNewExceptions": ["Q", "Q.Promise", "$.Deferred", "jQuery.Deferred"]}] }' src/

It would be easier if I could just pick a rule from my config (or the compiled config):

eslint --select-rule new-cap

Is there a way to achieve this already? Does that seem a good idea?

Thanks

PS: I'm running the latest ESLint on the 1.x branch

[IanVS]

Hi @customcommander. That's an interesting idea. I wonder if we could modify the behavior of --rule such that if you only provide a rule name, it uses the configuration from normal config file cascading rules. Would that solve your use case?

Alternatively, I've written eslint-nibble, which allows you to easily focus on cleaning up one rule at a time. That may be useful in your situation. (It's also still on eslint 1.x until I get around to updating it.)

[nzakas]

I don't think we need a new option for this. If you have a config file setup the way you want, set each rule's severity to 0 and include whatever other config info for that rule. Then, on the command line, use --rule 'new-cap: 2 to enable just the rule you want.

[IanVS]

@nzakas That's a bit of a pain though, since you'll have to be constantly re-configuring any options you want on each rule in turn after having turned them all to a 0. Yes, VCS can help ease the pain somewhat, but what do you think of my idea to allow --rule new-cap to use just that rule and its inherited configuration?

[IanVS]

I think I see the problem. The other rules will also run unless --no-eslintrc is also specified, which would disable the config for the one rule you do want. :(

[ilyavolodin]

I honestly think this is a solved problem: eslint ./ | grep "new-cap" or am I missing something?

[nzakas]

what do you think of my idea to allow --rule new-cap to use just that rule and its inherited configuration?

I think that's unexpected based on how --rule works already.

I'm just not sold on adding a new option for this use case. You can pretty easily create a filter for what ESLint outputs and do the same thing:

$ eslint . | grep "new-cap"

[IanVS]

OK, I'm sold. @customcommander, will one of these suggestions work for you?

[customcommander]

eslint | grep is what I'm doing already; it works fine but it obviously breaks your formatter output. I just thought that maybe some other users are having the same "issue" and could possibly do with some sugar :-)

I think I see the problem. The other rules will also run unless --no-eslintrc is also specified, which would disable the config for the one rule you do want. :(

I agree with @nzakas, that would be confusing. That's why I thought that a new rule would make more sense here: --select-rule new-cap would disable all the rules except that one.

Assuming that adding a new cli option is definitely off the table, what about a formatter that would group errors and warnings by rules instead of by files?

Example:

new-cap
foo.js: line 2
bar.js: line 123

strict
foo.js: line 1
bar.js: line 345

etc.

[IanVS]

@customcommander, did you take a look at eslint-nibble? It uses eslint-stats under the hood. You could take a look at that as a starting point if you wanted to create a reporter to group by rule.

[customcommander]

Yep something along those lines would work for me. However I don't need something interactive, a simple formatter would be enough, and also I'd rather depend on the original package than on a wrapper (no offence). Why not contributing some of it back to ESLint? It seems that some people started to "fork" ESLint for that purpose, surely this must be feature that other people would want to use :-)

[IanVS]

Yeah I understand. It's really intended to just be something you run when you're introducing ESLint to a project, and then for maintenance it's of course best to switch to ESLint directly, as you say.

If you write a formatter I bet we would consider rolling it into core. And even if it isn't part of core, you can still share and use it as a custom formatter.

[customcommander]

OK I'll give it a go and see what happens :-)

[nzakas]

I think the right approach fit note is to create a custom formatter. If we get other requests for the same thing, we can look at rolling a solution into core.

[customcommander]

Sounds reasonable. Thanks guys. (I'm working on it btw)

[shangxiao]

Please note this issue is useful with the --fix option

[niedzielski]

@rapilabs, I had a similar issue and followed the advice by @platinumazure in #6333. eslint --no-eslintrc --parser-options ecmaVersion:6 --rule no-var:error --fix ., in my case.

[samcday]

It'd be great to have this issue reopened for consideration. All the workarounds proposed here don't help if you want to selectively --fix particular rules.

In our case we have a pretty complex .eslintrc that extends a few base rulesets (like airbnb's eslint base) and configures stuff like an import/resolver.

If we run with --no-eslintrc then we get totally different results and have to restore a lot of other stuff to get consistency.

Let's take a simple example, indent. If you just do something like this:

eslint --no-eslintrc --rule "indent:[error,2]" --fix codez/

You get WAAAAY different results than if you use our main .eslintrc file. This is because things like how indentation should work in case statements and such are configured in settings which came from stuff we extended from in our .eslintrc.

I ended up working around this, but it was a little gross. I ran eslint --print-config .eslintrc.json > /tmp/tempconfig, manually edited that file to remove all but the rules I wanted, then ran eslint --config /tmp/tempconfig --fix codez/.

TL;DR I think it'd be great if core supported taking a fully formed configuration and then selectively running a single rule.

[IanVS]

FWIW, there's an accepted issue (#8039) to make some changes which would allow more control over what fixes are applied, if that is your main goal @samcday.