-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
Fix a rubocop offense #133
Conversation
This PR fixes a rubocop offense for `InternalAffairs/UndefinedConfig` ``` ❯ bundle exec rubocop Inspecting 50 files ...................C.............................. Offenses: lib/rubocop/cop/capybara/rspec/have_selector.rb:81:30: C: InternalAffairs/UndefinedConfig: DefaultSelector is not defined in the configuration for Capybara/RSpec/HaveSelector in config/default.yml. cop_config.fetch('DefaultSelector', 'css') ^^^^^^^^^^^^^^^^^ 50 files inspected, 1 offense detected ```
So we have to eat our own dogfood? Does this make sense? We have no capybara code here. I imagine the same will hit rubocop-minitest and rubocop-md, and rubocop-factory_bot, and other. It’s for rubocop itself and rubocop-rspec where this makes sense. It’s an internal cop, shouldn’t it be looking in config/default.yml for this? |
Going through the default config is fine for RuboCop itself but extensions need to inject their config for RuboCop to pick them up. This makes it necessary to load the extension, even if the extension itself doesn't use it, like `rubocop-rails` or `rubocop-capybara`. Instead just load config/default.yml from `Dir.pwd` in isolation and use just that. This would make rubocop/rubocop-capybara#133 and rubocop/rubocop-rails@288c7ce unnecessary I tested this against a bunch of extensions and the cop seems to continue its job. It also fixes a false positive in `rubocop-factory_bot`
Sounds reasonable, I openend rubocop/rubocop#13141 which would make this PR unnessesary. Let me know if something in that PR looks strange. It does indeed affect |
Going through the default config is fine for RuboCop itself but extensions need to inject their config for RuboCop to pick them up. This makes it necessary to load the extension, even if the extension itself doesn't use it, like `rubocop-rails` or `rubocop-capybara`. Instead just load config/default.yml from `Dir.pwd` in isolation and use just that. This would make rubocop/rubocop-capybara#133 and rubocop/rubocop-rails@288c7ce unnecessary I tested this against a bunch of extensions and the cop seems to continue its job. It also fixes a false positive in `rubocop-factory_bot`
Going through the default config is fine for RuboCop itself but extensions need to inject their config for RuboCop to pick them up. This makes it necessary to load the extension, even if the extension itself doesn't use it, like `rubocop-rails` or `rubocop-capybara`. Instead just load config/default.yml from `Dir.pwd` in isolation and use just that. This would make rubocop/rubocop-capybara#133 and rubocop/rubocop-rails@288c7ce unnecessary I tested this against a bunch of extensions and the cop seems to continue its job. It also fixes a false positive in `rubocop-factory_bot`
This PR fixes a rubocop offense for
InternalAffairs/UndefinedConfig
Before submitting the PR make sure the following are checked:
main
(if not - rebase it).CHANGELOG.md
if the new code introduces user-observable changes.bundle exec rake
) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).