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

Add new Rails/ZeitwerkFriendlyConstant cop. #748

Closed
wants to merge 1 commit into from

Conversation

bdewater
Copy link
Contributor

See rubocop/rails-style-guide#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.

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

Co-authored-by: Edouard CHIN <[email protected]>
Co-authored-by: Chris Salzberg <[email protected]>
@dvandersluis
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

dvandersluis commented Jul 25, 2022

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 😄

@koic
Copy link
Member

koic commented Jul 26, 2022

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
Copy link
Member

koic commented Sep 5, 2022

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

@koic koic closed this Sep 5, 2022
@xjunior
Copy link

xjunior commented Jan 5, 2023

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
Copy link

@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
Copy link
Contributor Author

bdewater commented Mar 11, 2023

@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

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

Successfully merging this pull request may close these issues.

5 participants