Add new Rails/ZeitwerkFriendlyConstant cop.

[bdewater]

See https://github.com/rubocop/rails-style-guide/pull/323

This cop is extracted from Shopify's internal Rubocop repository. Many thanks to the original authors for their work.

---

Before submitting the PR make sure the following are checked:

• [ ] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• [ ] Wrote good commit messages.
• [ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
• [ ] Feature branch is up-to-date with master (if not - rebase it).
• [ ] Squashed related commits together.
• [ ] Added tests.
• [ ] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• [ ] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.
• [ ] If this is a new cop, consider making a corresponding update to the Rails Style Guide.

[dvandersluis]

Rails comes with a zeitwerk:check rake task that finds issues by actually trying to load the code instead of doing static analysis. What would the use case for this cop be that that task doesn’t cover?

[bdewater]

I didn't know about that task, thanks for sharing. Looking at the code I can see one use case it doesn't provide: a gradual adoption approach using the Rubocop TODO file.

Alternatively the Rails rake task could use ActiveSupport::Deprecation so that things like Deprecation Toolkit could provide a similar way to disallow new bad examples being introduced while the existing code is being switched over component by component.

It is not practical to switch over a very large code base in a single change - but I can also appreciate not everybody having that problem :)

[dvandersluis]

Looking at the code I can see one use case it doesn't provide: a gradual adoption approach using the Rubocop TODO file.

While this is true, I'm not sure if it's of a lot of value. Zeitwerk is the default on Rails 6 and the only option on Rails 7, which means it's required to fix anything that Zeitwerk would complain about if you're upgrading to 7, or do not enable classic mode for the autoload, or else your app will just not boot.

Therefore I imagine you are using this as a way to transition to using Zeitwerk. I'm still not sure I'd do it in RuboCop, but perhaps leverage zeitwerk itself to create a code loading report that you could treat as a todo file. Doing static analysis is always going to be less ideal here, IMO.

Of course, since you already have an in-house cop for this, nothing is stopping you from using it if this is not accepted :smile:

[koic]

I agree with @dvandersluis's opinion and here is an interesting tweet I've seen recently: https://twitter.com/fxn/status/1551530582940782602

Perhaps CI check using the Zweitwerk official bin/rails zeitwerk:check instead of rubocop is the better place.

[koic]

I'll close this PR because @dvandersluis opinion seems reasonable. Thank you.

[xjunior]

This is useful for us. We have a pretty large application, so we'd like to migrate in chunks while prohibiting people from adding broken code.

[djlmills]

@bdewater Thanks for this. It has already been useful to quantify the naming issues in our monolith and delegate the work to fix them.

[bdewater]

@koic @dvandersluis I believe this should be re-opened. In addition to the above comments, zeitwerk:check doesn't detect this example I ran into (but the cop does):

# models/foo.rb
module Foo
end

module Bar
end

which has this load order bug:

[1] pry(main)> Bar
NameError: uninitialized constant Bar
from (pry):1:in `__pry__'
[2] pry(main)> Foo
=> Foo
[3] pry(main)> Bar
=> Bar