Rubocop: Extract Rails Cops in a separate

[bbatsov]

Rails cops have to extracted into a standalone gem (named something like rubocop-rails or whatever).

The reason for this decision is simple. I want RuboCop to be focused just on Ruby and have no framework/library/runtime dependant pieces for the sake of being easier to focus on evolving it. Creating more extensions should also help us come up with a good official API for them.

Any volunteers to do this? I don't do much Rails anymore, so I'd rather not be involved in this project if possible. @koic I know you've been working a lot on the Rails cops, so perhaps you'd like to tackle the extraction?

[Drenmi]

Unfortunately someone hogged the rubocop-rails name on RubyGems. I think the gem hosts the configuration used by the Rails team.

[bbatsov]

Yeah, I noticed this, but someone on RubyKaigi mentioned the guy would be willing to give the name up. I'm fine with naming the extension rubocop-ror or whatever.

[composerinteralia]

I would be happy to do this, or to help @koic do it. I wrote the couple of custom cops in rails and had a lot of fun doing it. (@koic I'm guessing we take those custom cops out of rails once the next rubocop version gets released. I would be happy to make that PR and to update rubocop-rails
as well unless you were planning to do it.)

[Drenmi]

@koic Maybe you can reach out to toshimaru about the name? His e-mail is registered in RubyGems.

[koic]

@bbatsov Yes. I will work on this issue. I'm thinking about planning now.

The following are issues and solutions for realizing this plan. There are still some issues to consider 🤔
Please let me know if you have any opinion.

RuboCop Rails Gem's name

As discussed above in this Issue, rubocop-rails gem already exists.
https://rubygems.org/gems/rubocop-rails

@Drenmi I'm asking @toshimaru whether he can transfer the gem name of rubocop-rails to the RuboCop team.

Even if toshimaru accepts the transfer gem name ownership, it seems necessary to announce to the current rubocop-rails gems (toshimaru/rubocop-rails) users, so we will need to talk to toshimaru about it.

@toshimaru Sorry to ask this of you, would you transfer rubocop-rails gem name to the RuboCop team, is it possible? I think that for the Rails department managed by RuboCop HQ, the name RuboCop Rails (rubocop-rails) is user-friendly as a convention.

Transition from RuboCop Core to RuboCop Rails

I'm thinking about the incompatibility impact on Rails department users.

Rails department users suddenly become surprised if Rails department cops are absent from RuboCop Core. I think that it is better to prepare the transition period.

So I'm considering the following transition procedure.

First, gemify RuboCop Rails and cut out.

• Copy the Rails department from RuboCop Core repo to RuboCop Rails repo
• Release RuboCop Rails gem (before this there is document description and some work :wink:)

Prepare the following warning for RuboCop Core.

• Announce the user by using post_install_message of rubocop.gemspec a warning that Rails department will be separated from RuboCop Core in the future.
  https://guides.rubygems.org/specification-reference/#post_install_message

For example, the following warning is considered.

DEPRECATION WARNING: Rails department is separated and will be removed in
RuboCop 0.y.z. Please use rubocop-rails gem.

Finally, remove the Rails department from RuboCop Core. We will need to consider when removting it.

However, this procedure temporarily duplicates Rails department to RuboCop Core repo and RuboCop Rails repo. Therefore maintenance may be twice troublesome, perhaps it may be better to temporarily s.add_runtime_dependency on RuboCop Rails from RuboCop Core (validation is required).

@composerinteralia I'd like to think about a happy procedure for the Rails community as well during the transition.

About the existing issues of the Rails department

I'm thinking about the method and cost of migrating the issue to RuboCop Rails. Perhaps I will leave the existing issues to the Rails department in the RuboCop Core repo as it is, and it seems good to treat it with RuboCop Rails repo only in future issues.

[bbatsov]

However, this procedure temporarily duplicates Rails department to RuboCop Core repo and RuboCop Rails repo. Therefore maintenance may be twice troublesome, perhaps it may be better to temporarily s.add_runtime_dependency on RuboCop Rails from RuboCop Core (validation is required).

I think that we can probably just cut out the new gem and show some instructions about adding the new gem when people try to enable the Rails cops. Seems this will be painless and won't really created breakages for the users (they'll just end up running fewer check temporary). I don't like much the idea of having the cops at some point in both RuboCop and RuboCop Rails, because this opens up the question of do we fix bugs in both gems or just in the new one.

We should leave some stubs for the Rails cops (or just some generic fallback logic) - e.g. each cop from the Rails department that's present in .rubocop.yml just generates a message that this cop does nothing and people need to install the new gem.

I agree that we should try to make this transition smooth, but I also think we shouldn't go overboard with it, as that's going to be one of the final big changes before 1.0. I think most users would forgive us some slight inconvenience now for the sake of long term stability.

[bbatsov]

I've created a repo https://github.com/rubocop-hq/rubocop-rails so you can start hacking there. We'll renaming it later if we fails to obtain the rubocop-rails name on RubyGems.

[koic]

We should leave some stubs for the Rails cops (or just some generic fallback logic) - e.g. each cop from the Rails department that's present in .rubocop.yml just generates a message that this cop does nothing and people need to install the new gem.

I see. I didn't think of it that way, and it looks good! 🌟
First we need gemifiy, so I will work on it. Thank you for letting me know.

[toshimaru]

@koic @bbatsov

would you transfer rubocop-rails gem name to the RuboCop team, is it possible?

Yes, It’s okay to give up the name if rubocop team really want it!

If I gave the name, who’d be the the author of the gem??

[Drenmi]

@toshimaru 🙇

[bbatsov]

@toshimaru I guess for now you can make me and @koic the owners. My handle on RubyGems is bozhidar, not sure about @koic's.

[koic]

@toshimaru I appreciate your acceptance very much. My RubyGems account is koic_ito ([email protected]). Thank you!

[koic]

The current situation. Currently, RuboCop Rails and Performance repositoies are extracting from Core using cp command. So, the git history has not been extracted now. This is inconvenient for future maintenance.

I'm investigating to extract some git history with git filter-branch or something.

After finishing the investigating, I'd like to proceed with application to the RuboCop Rails and Performance repositories. (And I may propose to RuboCop Performance first).

I appreciate your patience as it might take some time.

[bbatsov]

@koic Thanks for the update! I was wondering recently how are we doing on this front.

Hopefully you'll manage to find a way to preserve the history, but if you don't - we can live without it. It's not ideal, but it's not the end of the world either.

[koic]

FYI: I cherry-picked the git histories.

[bbatsov]

@koic Fantastic!

So what else remains before we can cut a release of rubocop-rails?

[koic]

@bbatsov Thanks!

I think this issue is aimed at extracting Rails department code from RuboCop Core in the future.
For that reason there is work remain to extract TargetRailsVersion from RuboCop Core to rubocop-rails. So I'm trying to extract TargetRailsVersion.

Also, I think there is some documentation about Rails department to be extracted. (Detailed documentation may be good even after release.)

[koic]

@bbatsov I have a question.

Do we extract metadata (#5978) to rubocop-rails and rubocop-performance from RuboCop Core?
If we extract metadata, we need to consider release versioning of rubocop-rails and rubocop-performance.

What do you have any ideas about this?

Related issue and PR: rubocop-hq/rubocop-rspec#699 and #6419.

[bquorning]

I am curious whether RuboCop-Rails and RuboCop-Performance would not be subject to the same namespace issues that RuboCop-RSpec has been seeing. RuboCop-RSpec has an RSpec/Rails/HttpStatus cop and an RSpec/FilePath cop that sometimes conflict with RuboCop’s Rails/HttpStatus and Rails/FilePath cops. See issues like https://github.com/rubocop-hq/rubocop-rspec/issues/611, https://github.com/rubocop-hq/rubocop/issues/5251, and https://github.com/rubocop-hq/rubocop-rspec/pull/710.

RuboCop-RSpec seemingly still needs the RuboCop::RSpec::Inject hack, which adds to my suspicion that we are not yet entirely ready to split out the Rails and Performance cops.

[bbatsov]

Do we extract metadata (#5978) to rubocop-rails and rubocop-performance from RuboCop Core?
If we extract metadata, we need to consider release versioning of rubocop-rails and rubocop-performance.

Yeah, we'll move the metadata to the gems. Each gem will have an independent release cycle, so ideally we'll have to come up with a reasonable stable extension API during the course of this extraction process. :-)

I am curious whether RuboCop-Rails and RuboCop-Performance would not be subject to the same namespace issues that RuboCop-RSpec has been seeing. RuboCop-RSpec has an RSpec/Rails/HttpStatus cop and an RSpec/FilePath cop that sometimes conflict with RuboCop’s Rails/HttpStatus and Rails/FilePath cops. See issues like rubocop-hq/rubocop-rspec#611, #5251, and rubocop-hq/rubocop-rspec#710.

We'll fix such issues while tackling the migration. None of them are particularly complex.

RuboCop-RSpec seemingly still needs the RuboCop::RSpec::Inject hack, which adds to my suspicion that we are not yet entirely ready to split out the Rails and Performance cops.

Well, it's widely known that RuboCop doesn't have a proper extension API right now, but the best way to devise the API (mostly a ways for extensions to registers themselves properly, without the need for custom hacks) is to actually write a few extensions that will help the API emerge and stabilize. :-)

[koic]

rubocop-rails 2.0.0 has been released 🚀
https://rubygems.org/gems/rubocop-rails/versions/2.0.0

[bbatsov]

Fantastic work! 🙇

[halfbyte]

Can someone please add a short note in the rubocop-rails README about the renaming/owner change?

I am inclined to say that the name takeover is a bad idea that should have never happened (from a platform stability standpoint) but I also know that it's way too late to chime in on that. You are probably aware that the yanking is also gonna break a ton of builds of the users of the old gem, so there's that as well.

In any case, not mentioning this anywhere in the README will leave a lot of people quite confused as to what exactly has happened, so it would be great if you could fix that.