It seems some people are frustrated by the fact they have to manually enable/disable pending cops (see https://github.com/rubocop-hq/rubocop/issues/7771). This also came up a few times in the RuboCop defaults survey.
We should add configuration option allowing pending cops to be treated as pending (default), enabled or disabled by default. This would allow everyone to decide how to best handle those those.
I don't think there are any better alternatives.
@rubocop-hq/rubocop-core Any thoughts on this?
I think that the new feature will lead to a solution. I'm considering command line and configuration options.
Run including pending cops.
% rubocop --with-pending-cops
Run excluding pending cops.
% rubocop --without-pending-cops
In addition, it is an example to specify in .rubocop.yml instead of the command line option. These configuration values have the same meaning as the Enabled option's values.
AllCops:
EnabledNewCops: pending # default
AllCops:
EnabledNewCops: true
AllCops:
EnabledNewCops: false
Maybe option and configuration names could be considered further.
% rubocop --with-pending-cops
I'm fine with the proposal but let's use naming like --enable/disable-pending-cops instead. I think that's easier to understand.
AllCops:
EnabledNewCops: pending # default
Yeah, that's more or less what I had in mind. I guess the option can be named "NewCops" and have potential values "enable", "disable", "pending". Generally, we can go only with the command-line option, as users can put it in their .rubocop if they want to use it all the time.
These naming sounds easy to understand 馃専I will take this issue!
I think it's worth mention that final variant in rubocop 0.82.0
not
AllCops:
EnabledNewCops: true
But
AllCops:
NewCops: enable
EnableNewCops: true seems like a good name, however NewCops accepts three values: enalbe, disable, and pending.
Thank you thank you thank you
Most helpful comment
I think it's worth mention that final variant in rubocop 0.82.0
not
But