Config loads differently than basic RuboCop

skryukov / rubocop-gradual

Gradually improve your code with RuboCop

MIT License

36 stars 0 forks source link

Config loads differently than basic RuboCop #17

Closed pboling closed 11 months ago

pboling commented 11 months ago

I have a large config, with many RuboCop plugins (see rubocop-lts meta gem), and when I run with NO_GRADUAL=1 different cops run that when I run rubocop-gradual normally. I'm not sure of much else yet, but I will update here as I figure things out.

pboling commented 11 months ago

I have also seen now that when I run with NO_GRADUAL=1 bundle exec rubocop and:

have commented the inherit_gem directives, to skip the gems' rules:
- the rules directly below, in the local .rubocop-yml file, apply
have uncommented the inherit_gem directives, to load the gems' rules:
- the rules directly below, in the local .rubocop-yml file, are ignored
- even though they should have the highest precedence

At minimum, some of the bug is in RuboCop core.

skryukov commented 11 months ago

Do you mean inherit_gem? Could you provide a minimal reproduction for that bug, I tried this config and it worked fine for me (i.e. Foo.find_by_id(1) was always ignored):

require:
  - rubocop-gradual
  - rubocop-rails

inherit_gem:
  rubocop-rails:
    - config/default.yml

Rails/DynamicFindBy:
  Enabled: false

pboling commented 11 months ago

Yes, corrected. I think the issue is likely entirely inside RuboCop, and I think it is caused by an entire department being disabled in the gem's config, and then no matter what you do you can't enable a specific rule from that department. I've reported it here: https://github.com/rubocop/rubocop/issues/12315

pboling commented 11 months ago

Closing in favor of the idea that this is mostly within core RuboCop.

Note that the number of violations found by RuboCop changes when I run with and without NO_GRADUAL=1, but I can't address that reliably until the core bug is fixed.

This issue shouldn't hold up a release here.