Skip to content
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

inherit_gem does not inherit AllCops #10175

Closed
grosser opened this issue Oct 8, 2021 · 3 comments
Closed

inherit_gem does not inherit AllCops #10175

grosser opened this issue Oct 8, 2021 · 3 comments

Comments

@grosser
Copy link
Contributor

grosser commented Oct 8, 2021

Expected behavior

require: standard

inherit_gem:
  standard: config/base.yml

should inherit DisabledByDefault: true from https://github.com/testdouble/standard/blob/main/config/base.yml#L7

Actual behavior

It does not and rules that are not explicitly disabled are showing up

test/watching_test.rb:77:121: C: [Correctable] Layout/LineLength: Line is too long. [125/120]

Steps to reproduce the problem

Use config as above with standard (1.3.0)

RuboCop version

1.22.1 (using Parser 3.0.2.0, rubocop-ast 1.12.0, running on ruby 2.7.2 x86_64-darwin19)
@andyw8
Copy link
Contributor

andyw8 commented Dec 8, 2021

Just a note that this issue was referenced in https://thoughtbot.com/blog/a-standard-way-to-lint-your-views

@jonas054
Copy link
Collaborator

jonas054 commented Apr 2, 2022

I tried to reproduce with these files:

$ find . -type f | xargs head -100
==> ./test/watching_test.rb <==
puts "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"

==> ./.rubocop.yml <==
require: standard

inherit_gem:
  standard: config/base.yml

==> ./Gemfile.lock <==
GEM
  remote: https://rubygems.org/
  specs:
    ast (2.4.2)
    parallel (1.22.1)
    parser (3.1.1.0)
      ast (~> 2.4.1)
    rainbow (3.1.1)
    regexp_parser (2.2.1)
    rexml (3.2.5)
    rubocop (1.20.0)
      parallel (~> 1.10)
      parser (>= 3.0.0.0)
      rainbow (>= 2.2.2, < 4.0)
      regexp_parser (>= 1.8, < 3.0)
      rexml
      rubocop-ast (>= 1.9.1, < 2.0)
      ruby-progressbar (~> 1.7)
      unicode-display_width (>= 1.4.0, < 3.0)
    rubocop-ast (1.16.0)
      parser (>= 3.1.1.0)
    rubocop-performance (1.11.5)
      rubocop (>= 1.7.0, < 2.0)
      rubocop-ast (>= 0.4.0)
    ruby-progressbar (1.11.0)
    standard (1.3.0)
      rubocop (= 1.20.0)
      rubocop-performance (= 1.11.5)
    unicode-display_width (2.1.0)

PLATFORMS
  x86_64-linux

DEPENDENCIES
  standard (~> 1.3.0)

BUNDLED WITH
   2.2.22
==> ./Gemfile <==
source "https://rubygems.org"

gem "standard", "~> 1.3.0"

and ran:

$ bundle install; bundle exec rubocop -d -C false
Using ast 2.4.2
Using bundler 2.2.22
Using parallel 1.22.1
Using parser 3.1.1.0
Using rainbow 3.1.1
Using regexp_parser 2.2.1
Using rexml 3.2.5
Using rubocop-ast 1.16.0
Using ruby-progressbar 1.11.0
Using unicode-display_width 2.1.0
Using rubocop 1.20.0
Using rubocop-performance 1.11.5
Using standard 1.3.0
Bundle complete! 1 Gemfile dependency, 13 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
For /home/jonas/dev/issues/rubocop/10175: configuration from /home/jonas/dev/issues/rubocop/10175/.rubocop.yml
Inheriting configuration from /home/jonas/.rvm/gems/ruby-3.0.0/gems/standard-1.3.0/config/base.yml
configuration from /home/jonas/.rvm/gems/ruby-3.0.0/gems/rubocop-performance-1.11.5/config/default.yml
configuration from /home/jonas/.rvm/gems/ruby-3.0.0/gems/rubocop-performance-1.11.5/config/default.yml
Default configuration from /home/jonas/.rvm/gems/ruby-3.0.0/gems/rubocop-1.20.0/config/default.yml
Inspecting 2 files
Scanning /home/jonas/dev/issues/rubocop/10175/Gemfile
.Scanning /home/jonas/dev/issues/rubocop/10175/test/watching_test.rb
.

2 files inspected, no offenses detected
Finished in 0.27110992099915165 seconds

So no offenses are found. DisabledByDefault seems to work as expected.

When you get the problem, could it be that RuboCop loads another version of the config file from standard?

@grosser
Copy link
Contributor Author

grosser commented Apr 9, 2022

Thx for trying to reproduce!
DisabledByDefault is no longer in use by standard gem so this issue is solved for me.

@grosser grosser closed this as completed Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants