Rubocop: RuboCop ignore file

[palkan]

Is your feature request related to a problem? Please describe.

RuboCop has a default Exclude configuration (https://github.com/rubocop-hq/rubocop/blob/v0.61.1/config/default.yml#L60-L63), which covers only basic use-cases.

If you define your own AllCops -> Exclude directive, it overrides the default one and not merged into it.

I've been confused by this behaviour multiple times: you add global Exclude to your .rubocop.yml and then your CI build "suddenly" fails due to the presence of Ruby files in vendor/ directory. The first couple of times you think "Why did this work before?"; after that–"Ah, I forgot to add vendors/ to Exclude".

NOTE: there is an inherit_mode directive to change this behaviour. Raise you hand if you heard about it.

For example, my typical .rubocop.yml contains the following:

# auto-generated binstubs
- 'bin/*'
# temp files
- 'tmp/**/*'
# node_modules could contain Ruby code
- 'node_modules/**/*'
# vendor/ dir is used by most CI services
- 'vendor/**/*'

Describe the solution you'd like

I'm thinking about a different way of handling ignores–using .rubignore file similar to .gitignore.

That would bring familiar git-like approach for ignoring files to RuboCop.

No need to think about directives, configs inheritance, merging strategies.

The default ignore file could be generated automatically using a CLI command.

Describe alternatives you've considered

Setting inherit_mode to merge for Exclude by default.

Cons:

• breaking change.

Additional context

https://github.com/testdouble/standard/issues/42

[jaredbeck]

I've been confused by this behaviour multiple times ..

Me too. I think this will continue to surprise people. People expect Exclude arrays to be merged by default, however ..

Setting inherit_mode to merge for Exclude by default.

This suggestion has already been discussed, eg. https://github.com/rubocop-hq/rubocop/issues/4477#issuecomment-306976350

inherit_mode .. Raise you hand if you heard about it.

I am sure you are right that few have heard of it. I have worked on those docs (eg. https://github.com/rubocop-hq/rubocop/pull/6154) :smile: so if you have suggestions for them please let me know.

I'm thinking about a different way of handling ignores–using .rubignore file similar to .gitignore.

I like the idea of borrowing a familiar concept from git, but I wouldn't want to add another type of configuration file. Though there is already the potential for many rubocop configuration files in a project, at least they all have the same data format.

[rmacklin]

FWIW, eslint makes use of both its own config file as well as a separate .eslintignore file.

Only sharing to offer an example of this pattern in a similar linting tool.

[MrAtheist]

Anyone can chime in as to why my Allcops -> Exclude is ignored...?

.rubocop.yml

inherit_from:
  - .rubocop_todo.yml
  - .rubocop_app_overrides.yml

inherit_mode:
  merge:
    - Exclude

Rails:
  Enabled: true

AllCops:
  TargetRubyVersion: 2.5.1
  EnabledByDefault: true
  Exclude:
    - 'db/**/*'
    - 'config/**/*'
    - 'script/**/*'
    - 'bin/{rails,rake}'
    - !ruby/regexp /old_and_unused\.rb$/

rubocop cmd: rubocop --except Metrics/LineLength,Metrics/MethodLength --parallel

[MrAtheist]

Found this bit --force-exclusion that works for me:
https://github.com/rubocop-hq/rubocop/issues/2492

[jonas054]

I think it's time to close this issue. The current path of adding an Exclude in user configuration, not getting the excludes you expect, consulting the on-line manual, discovering inherit_mode, and fixing it, is good enough in my opinion. Adding more ways of excluding is adding more headache, I believe.

[jaredbeck]

Not sure how easy this is to do, but what do y'all think about having --debug list the relevant inclusion/exclusion configuration for a particular file. For example:

Scanning ./foo/bar.rb
Excluded by ./foo/.rubocop.yaml, then included by ./.rubocop.yaml

If there's any maintainer interest, I'll open a new issue for further discussion.

[jonas054]

@jaredbeck I'm not sure either how much work it would be, but it's a good feature.