-
-
Notifications
You must be signed in to change notification settings - Fork 277
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 RSpec/RemoveConst cop #1749
Add new RSpec/RemoveConst cop #1749
Conversation
6345386
to
a3b8236
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good already. Up to you if you want to enhance this to detect const removal at any level.
Thank you for the contribution!
4a26dc5
to
42dc2ab
Compare
Could you run |
oops, I thought I did this already, I'll have a look |
42dc2ab
to
775ad8f
Compare
ah, had to re-run the task because I adapted the documentation in the code. pushed :) |
# before do | ||
# SomeClass.send(:remove_const, :SomeConstant) | ||
# end | ||
# |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to add an exqmple with stub_const
as good?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good question 🤔 We had some spec helper that used Object.remove_const
and Object.const_set
to change a global config in our specs. This caused several issues in our CI so I added this as an example. But I'm no longer sure if this is a good example in the wild?
|
||
# @!method remove_const(node) | ||
def_node_matcher :remove_const, <<~PATTERN | ||
(send _ {:send | :__send__} (sym :remove_const) _) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More a comment for @pirj than for @swelther:
I don’t know that the |
is necessary, but I found that any of these 3 patterns will let the current specs pass:
(send _ {:send | :__send__} (sym :remove_const) _)
(send _ {:send :__send__} (sym :remove_const) _)
(send _ {:send __send__} (sym :remove_const) _)
Curiously, (send _ {:send | __send__} (sym :remove_const) _)
will not work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha, another node pattern related gotcha gotcha in the same PR!
Agree, |
is optional, but it actually helped finding a match-all node.
__send__
is a named “any node”, basically the same as _
. https://docs.rubocop.org/rubocop-ast/node_pattern.html had an example with (int _value)
. I think we used that in our cops, too, but it’s not documented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so, do I need to change something? Sorry, I'm a bit lost here 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You may want to remove the | as it’s redundant, or to keep it for failsafe. Up to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the |
syntax more because it looks like regex and might be easier to understand. Would like to keep it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the docs I found this bit:
If all the branches have a single term, you can omit the
|
, so{int | float}
can be simplified to{int float}
.
So, apparently it’s valid syntax – I just hadn’t seen it before 😳 Let’s just leave the |
in.
775ad8f
to
754e75d
Compare
Following the recent introduction of a new cop in Rubocop, Rspec/RemoveConst, our CI has started failing. It seems like this rule is being enforced as a good practice to avoid buggy debug information but no real alternative is being offered. This commit disables the cop to allow the CI to continue working. Here are the discussions that led to the creation of the rule: rubocop/rubocop-rspec#1748 rubocop/rubocop-rspec#1749
This PR adds a cop that forbids the usage of
Object.remove_const
in specs. We had some strange errors and side effect because of this usage in our project and wanted to get rid of the usage in specs and rise awareness, so we created the cop. (Fixes #1748)Before submitting the PR make sure the following are checked:
master
(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).If you have created a new cop:
config/default.yml
.Enabled: pending
inconfig/default.yml
.Enabled: true
in.rubocop.yml
.VersionAdded: "<<next>>"
indefault/config.yml
.