-
Notifications
You must be signed in to change notification settings - Fork 115
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
rubocop/config/default: Unset DisabledByDefault
#1531
rubocop/config/default: Unset DisabledByDefault
#1531
Conversation
- The `DisabledByDefault` config option made it so that "all cops in the default configuration are disabled, and only cops in user configuration are enabled", which makes cops "opt-in rather than opt-out" (source: https://github.com/rubocop/rubocop/blob/d1270c468cdb9a211229e36aef8d568ae3bfe607/config/default.yml#L91-L102). - It's not immediately obvious that this gem has this config option. This means that people may write new, custom cops in downstream projects, with no configuration in .rubocop.yml, and then they never run because all cops are disabled unless explicitly enabled or otherwise configured with `Include`/`Exclude`. - RuboCop does not warn users that the config inheritance has set `DisabledByDefault` somewhere up the line, leading to users mistakenly not enabling cops they may have intended to. - Other of GitHub's open source gems, like `rubocop-github`[1] and `rubocop-rails-accessibility`[2], have moved away from `DisabledByDefault`. This is the last one (at least that I can find in GitHub's main project's RuboCop gem inheritance tree). [1] - github/rubocop-github#119 [2] - github/rubocop-rails-accessibility#7
🦋 Changeset detectedLatest commit: be6fe65 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clear explanation. This should be in the next release 105, probably out next week
Hey @issyl0, unfortunately we need to revert this PR because it's causing an issue with our CI builds at the moment. The problem is erblint only looks at snippets of Ruby code, eg |
This reverts commit 58436f7.
Ok, it looks like disabling cops can be done directly inside .erb-lint.yml 🎉 Here's the PR: #1535 |
Thanks and sorry for the friction here @camertron, I didn't know you used |
Description
DisabledByDefault
config option made it so that "all cops in the default configuration are disabled, and only cops in user configuration are enabled", which makes cops "opt-in rather than opt-out" (source: https://github.com/rubocop/rubocop/blob/d1270c468cdb9a211229e36aef8d568ae3bfe607/config/default.yml#L91-L102).Include
/Exclude
.DisabledByDefault
somewhere up the line, leading to users mistakenly not enabling cops they may have intended to.rubocop-github
[1] andrubocop-rails-accessibility
[2], have moved away fromDisabledByDefault
. This is the last one (at least that I can find in GitHub's main project's RuboCop gem inheritance tree).[1] - github/rubocop-github#119
[2] - github/rubocop-rails-accessibility#7
Integration
Nope.
Merge checklist