Split up to cover more ground

[pirj]

We now have several major departments:

• RSpec
• Rails (for rspec-rails)
• FactoryBot (for factory_bot)
• Capybara (for capybara)

Our project is (from different sources) "Code style checking for RSpec files" and "RSpec-specific analysis for your projects".

The latter two, besides RSpec work with:

• Test::Unit
• Cucumber
• Minitest
• Minitest::Spec

Wondering if users of those testing frameworks could benefit from using our cops without adding RSpec cops.
Well, they can do it with e.g.:

# .rubocop.yml
RSpec:
  Enabled: false
RSpec/FactoryBot:
  Enabled: true

The only one I'd keep out of the FactoryBot-related department is RSpec/FactoryBot/SyntaxMethods, as it suggests including a module and skip use FactoryBot DSL methods from specs without an explicit FactoryBot receiver.

For Capybara, it's half by half RSpec and pure Capybara at a glance.

For Rails department, all cops are RSpec-specific.

It's not that it's urgent, and neither the number of semi-related cops is overwhelming (7-8 at best).
Just an idea to split into several repos and gems.
Release wise, keep one major (3.0?) rubocop-rspec version to depend on rubocop-capybara and rubocop-factory_bot, but in 4.0, remove those dependencies and make a note to install and configure them separately, and only ship RSpec-related in rubocop-rspec.

[Darhazer]

Recently I was thinking the same - it's time to extract FactoryBot and Capybara checks under their own space. We can then make rubocop offer the specific cops based on the installed gems, and we can have the 3.0 release without them

[pirj]

I was able to change the base for the following cops from ::RuboCop::RSpec::Cop::Base to ::RuboCop::Cop::Base:

 M lib/rubocop/cop/rspec/capybara/current_path_expectation.rb
 M lib/rubocop/cop/rspec/capybara/negation_matcher.rb
 M lib/rubocop/cop/rspec/capybara/specific_actions.rb
 M lib/rubocop/cop/rspec/capybara/specific_finders.rb
 M lib/rubocop/cop/rspec/capybara/specific_matcher.rb
 M lib/rubocop/cop/rspec/capybara/visibility_matcher.rb
 M lib/rubocop/cop/rspec/factory_bot/attribute_defined_statically.rb
 M lib/rubocop/cop/rspec/factory_bot/consistent_parentheses_style.rb
 M lib/rubocop/cop/rspec/factory_bot/create_list.rb
 M lib/rubocop/cop/rspec/factory_bot/factory_class_name.rb
 M lib/rubocop/cop/rspec/rails/avoid_setup_hook.rb
 M lib/rubocop/cop/rspec/rails/have_http_status.rb
 M lib/rubocop/cop/rspec/rails/http_status.rb

with a small change required in just two of them (capybara/current_path_expectation.rb, rspec/rails/have_http_status.rb):

- #Runners.all
+ {:to :not_to :to_not}

which is now I think was a mistake to make a part of a config. Unlike other DSL elements, there is no obvious way to alias them. HookScopes is another such example.

PS fixed in #1459

[pirj]

I was thinking we may actually make the transition smoother.

This, I believe, can be done in a minor version:

1. Extract cops to their own gems
2. Add dependencies on those gems
3. Make a local copy of those cops RuboCop::Cop::RSpec::Capybara::NegationMatcher = RuboCop::Cop::Capybara::NegationMatcher
4. Keep config defaults for those old cop names in rubocop-rspec
5. Add obsoletion config that would warn users about new cop names, but won't break since we keep the old config, too

In a major version update, we can remove dependencies on those gems and remove their configs from rubocop-rspec, and tell users to add those gems explicitly to their dependencies and .rubocop.yml config files.

[ydah]

@pirj Great job on the RuboCop Capybara extraction🎉

I'm sure we'll move forward with other extractions in the future, but I'm also interested in this topic and would like to help.

If there's anything I can do to help, please let me know! (although I may be limited in what I can do since I'm not a member of the RuboCop core team and I'm not a collaborator to RuboCop RSpec 😅)

[pirj]

Thank you! I’ve started in the same position, I don’t have permissions to create repos under rubocop namespace, so I went with a repo under my name. Also, the extraction pr doesn’t require any special permissions. We can split factory bot and rspec rails. Pick the one that you like most.

[ydah]

I’ve started in the same position, I don’t have permissions to create repos under rubocop namespace, so I went with a repo under my name.
Also, the extraction pr doesn’t require any special permissions.
We can split factory bot and rspec rails. Pick the one that you like most.

Thank you 😀! Now I will attempt to extract factory_bot.

[bquorning]

Would anyone be up for extracting the Rails cops, I guess into a https://github.com/rubocop/rubocop-rspec-rails/ repo? (#1734)

[ydah]

@bquorning If it's okay with me, I'll do it. I will start working on it next week.

[bquorning]

That would be great @ydah 👍🏼

[ydah]

It’s all done! Thank you @bquorning , @pirj , @Darhazer and everyone 🚀