Rubocop 0.80.0 outputs warnings about newly introduced cops

[tagliala]

When providing a configuration file to Rubocop 0.80.0, I see three warnings related to

• Style/HashEachMethods
• Style/HashTransformKeys
• Style/HashTransformValues

Does not happen with RuboCop 0.79.0

I'm testing the current master branch

---

Expected behavior

Do not see warnings

Actual behavior

$ rubocop -V
0.80.0 (using Parser 2.7.0.2, running on ruby 2.7.0 x86_64-darwin19)
$ rubocop
The following cops were added to RuboCop, but are not configured. Please set Enabled to either `true` or `false` in your `.rubocop.yml` file:
 - Style/HashEachMethods
 - Style/HashTransformKeys
 - Style/HashTransformValues

Steps to reproduce the problem

$ touch test.rb
$ touch .rubocop.yml
$ rubocop

RuboCop version

0.80.0 (using Parser 2.7.0.2, running on ruby 2.7.0 x86_64-darwin19)

Include the output of rubocop -V or bundle exec rubocop -V if using Bundler. Here's an example:

$ [bundle exec] rubocop -V
0.80.0 (using Parser 2.7.0.2, running on ruby 2.7.0 x86_64-darwin19)

[ShockwaveNN]

Also this broke overcommit integration

[tagliala]

Ref:

• https://github.com/rubocop-hq/rubocop/blob/master/config/default.yml#L2793
• https://github.com/rubocop-hq/rubocop/blob/master/config/default.yml#L2822
• https://github.com/rubocop-hq/rubocop/blob/master/config/default.yml#L2827

[bbatsov]

That's a feature. :-) As many users were complaining that when new cops were introduced this caused CI failures and extra code fixing work, we decided to just list the new cops that were added and leave it to the users to enable/disable them.

Note that those are not warnings - just informative messages.

[bbatsov]

See #7567 and #5979 for more details.

[ShockwaveNN]

But I don't think broken overcommit integration is look like a feature, or is this better to discuss with overcommit team?

[bbatsov]

But I don't think broken overcommit integration is look like a feature

I was referring to the description of the issue.

or is this better to discuss with overcommit team?

I think that'd be best. I'm sorry to hear the change caused a breakage, but I've never used the tool, so I'm not sure what this integration looks like. We're always willing to help 3rd party tools that want to leverage RuboCop.

[ShockwaveNN]

@bbatsov Ok, thanks. Created an issue at overcommit - sds/overcommit#704

[tagliala]

That's a feature. :-) As many users were complaining that when new cops were introduced this caused CI failures and extra code fixing work, we decided to just list the new cops that were added and leave it to the users to enable/disable them.

Hi @bbatsov , thanks for the clarification!

So every new cop will have "Enabled: pending" and we should decide if we want them or not in our own rubocop.yml?

[bbatsov]

Yes. RuboCop will update the pending status to enabled/disable only for major releases (similar to what ESLint does).

We'll likely cut RuboCop 1.0 is the next couple of months.

[tagliala]

@bbatsov is there any command line options to enable by default the newly introduced cops?

Use case:

• I have a folder with just a ruby file
• I run rubocop -a
• I want all cops to be run against the file in the folder, without having to create a .rubocop.yml file