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
Rubocop v0.87+ compatibility #179
Conversation
* Pegs simplecov * Pegs Blacklight to no greater than 7.5.0 * UPDATE gems * rubocop 0.87.1 → 0.86.0 [changelog](https://github.com/rubocop-hq/rubocop/blob/master/CHANGELOG.md#0860-2020-06-22) * Had to downgrade rubocop due to Shopify/erb-lint#179
Hi, It's been almost 2 weeks. Why is PR not merged? |
Thank you for your contribution, and sorry for not responding earlier. Shopify is dramatically cutting back on the use of |
lib/erb_lint/corrector.rb
Outdated
end | ||
|
||
def diagnostics | ||
corrector.diagnostics | ||
if defined?(::RuboCop::Cop::Base) |
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'm not sure I understand what's going on here. Are you using the existence of ::RuboCop::Cop::Base
to deduce whether ::RuboCop::Cop::Legacy::Corrector
exists?
If that's the case, would it be an option to just check for the existence of rubocop/cop/legacy/corrector
?
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.
Are you using the existence of
::RuboCop::Cop::Base
to deduce whether::RuboCop::Cop::Legacy::Corrector
exists?
Yes
would it be an option to just check for the existence of rubocop/cop/legacy/corrector?
Yes, but I'm not sure I understand how you are proposing to do that exactly, or the benefits.
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.
Actually, I'm using it to deduce if ::RuboCop::Cop::Legacy::Corrector
exists and which API to use...
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'm trying to find out what the actual desired semantics are. As this condition is repeated throughout the diff and you don't seem to be using ::RuboCop::Cop::Base
directly anywhere, I guess you're looking for whether or not the rubocop version used is 0.87+
?
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.
Yes, a check on version number would be equivalent
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 think I'd rather have a check on the version number as that means it'd be more obvious when to remove the added code paths.
But I'm also interested in hearing what @thegedge thinks about this.
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.
it'd be more obvious when to remove the added code paths.
That's a good point 👍
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.
Agreed, a version check would definitely make this a little clearer in terms of when we should remove.
Ideally, we would better abstract away the details of Rubocop, but that's outside the scope of this PR. One thing this PR highlights is all the coupling points 🙂
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.
Ok, let me switch to version check then.
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.
Done
@@ -63,7 +63,7 @@ def autocorrect(processed_source, offense) | |||
string = offense.source_range.source | |||
return unless (klass = load_corrector) | |||
return unless string.strip.length > 1 | |||
node = RuboCop::AST::StrNode.new(:str, [string]) | |||
node = ::RuboCop::AST::StrNode.new(:str, [string]) |
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.
What's the reason for explicitly fully qualifying the Rubocop
references?
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.
The first thing I wanted to check in the code was all dependencies on RuboCop
. Given that erb_lint
has a class called Rubocop
(no capital 'C' though), this wasn't perfectly clear at first so I thought that it was a good idea to do this, instead of relying on the context or how the letter 'c' is capitalized.
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'm 👍 with fully qualifying external references (in general), but especially if there's a similarly named thing internally.
Fair warning - Shopify is not working Fridays right now and I'm running out of time for today, I'll get back to you next week. |
lib/erb_lint/linters/rubocop.rb
Outdated
activate_team(processed_source, source, offset, code_node, build_team) | ||
end | ||
|
||
if ::RuboCop::Version::String.to_f >= 0.87 |
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.
Why do these conditions on a class level, instead of inside the method body?
Is this just to avoid repeated .to_f >= 0.87
at runtime?
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.
Yes. More efficient, and I find it cleaner this way; it makes it clear what actions need be different according to the version.
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 was actually thinking the opposite, because your version duplicates some code, instead of just putting the conditionals around the code that is actually different.
But I don't have a strong opinion on this; either way it's clear what to remove.
Thank you for structuring your changes into separate commits, makes the review so much easier 👍 |
lib/erb_lint/corrector.rb
Outdated
end | ||
|
||
def diagnostics | ||
corrector.diagnostics | ||
if ::RuboCop::Version::String.to_f >= 0.87 |
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.
Looking at the tests, it seems that you need to
if ::RuboCop::Version::String.to_f >= 0.87 | |
if ::RuboCop::Version::STRING.to_f >= 0.87 |
OK, I'm getting close to a ✅ in my mind 😄 The main thing that I'm concerned with at this point is that we're not testing both code paths. I wonder if we could configure travis to do separate builds for old-rubocop vs new-rubocop. If that leads to too many build variations we may want to think about dropping Ruby 2.4.1 |
We should probably do that anyways, since Ruby 2.4 is EOL (and 2.5 is soon to be EOL). |
I didn't make changes to the |
working on a setup to test both code paths in #181 |
I'd love to get the CI setup figured out first, cherry-pick it over here and merge both together |
Yeah, I'd like to see the ✅ for both the old and new Rubocop, but otherwise everything looks good to me. Thanks for your contribution, @marcandre. Sorry it took so long for us get to it 😓 |
We want to test code paths specific to these new APIs while still also testing the old code paths for compatibility
Cherry-picked, all green. |
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.
🎉
Thank you so much for your contribution, and the persistence!
Rubocop 0.87 is a prelude to 1.0 and introduces major refactoring of internal classes, some of which are used by
erb-lint
.This PR maintains compatibility.
Note that this needs the very latest
parser
to use the newTreeRewriter#import
feature.