Skip to content
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

Opting in to cops on a cop-by-cop basis? #986

Closed
fj opened this issue Apr 10, 2014 · 6 comments · Fixed by #994
Closed

Opting in to cops on a cop-by-cop basis? #986

fj opened this issue Apr 10, 2014 · 6 comments · Fixed by #994

Comments

@fj
Copy link

fj commented Apr 10, 2014

The documentation doesn't seem to cover the following use case:

  • Run all the Lint cops.
  • Only run some of the Style cops, on an opt-in basis, using .rubocop.yml.
  • Don't run any other cops.

Is something like that possible?

@fj fj changed the title Opting in to cops? Opting in to cops on a cop-by-cop basis? Apr 10, 2014
@bbatsov
Copy link
Collaborator

bbatsov commented Apr 10, 2014

Run all the Lint cops.

rubocop -l (this is mentioned in the README)

Only run some of the Style cops, on an opt-in basis, using .rubocop.yml.

Don't think that is possible at the moment (at least directly). @jonas054 might have more insight. I guess you can have a config that disabled all cops out-of-the box, inherit from it, and enable only the cops you want to enable.

Don't run any other cops.

Not sure what you mean. You can run a single cop with:

rubocop --only CopName

@fj
Copy link
Author

fj commented Apr 10, 2014

Sorry, I don't think I was clear: I was describing one use case that covered all three of those bullets, not three separate cases. You're right that rubocop -l would handle the first one nicely.

That is, I want to run every Lint cop, and only some of the Style cops, and none of the other cops. It sounds like the best place to start is a config that explicitly disables every cop, but that would break as soon as any new cop is introduced, right?

@jonas054
Copy link
Collaborator

The way to achieve this is, as you suggest @fj, to copy config/enabled.yml, save it under the name .rubocop.yml and replace Enabled: true with Enabled: false for all the style cops you don't want to run. Rails cops (the other cops) are not run by default.

But you're right that it would break when style cops are added in later versions. There's no way to disable by default and opt in. If we want to add such functionality, I think the best way would be to

  • allow a comma-separated list of cops for the --only option
  • let rubocop --lint --only COPS mean to run all lint cops plus the listed COPS (today the --lint option is dropped with no warning)

@bbatsov
Copy link
Collaborator

bbatsov commented Apr 10, 2014

👍 for running multiple cops with --only and allowing the combination of --lint and --only.

@fj
Copy link
Author

fj commented Apr 10, 2014

OK, I think that should be a comparatively straightforward task.

I can work on a pull request, but I just want to point out that this would be a breaking change (rubocop --lint --only COPS means something different now than it will after the pull request is completed). Is that acceptable?

@bbatsov
Copy link
Collaborator

bbatsov commented Apr 10, 2014

Yes, this is acceptable. We're pretty far away from a 1.0 release anyways. —
Sent from Mailbox for iPhone

On Thu, Apr 10, 2014 at 7:34 PM, John Feminella notifications@github.com
wrote:

OK, I think that should be a comparatively straightforward task.

I can work on a pull request, but I just want to point out that this would be a breaking change (rubocop --lint --only COPS means something different now than it will after the pull request is completed). Is that acceptable?

Reply to this email directly or view it on GitHub:
#986 (comment)

jonas054 added a commit to jonas054/rubocop that referenced this issue Apr 11, 2014
jonas054 added a commit to jonas054/rubocop that referenced this issue Apr 11, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants