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

Rubocop v0.87+ compatibility #179

Merged
merged 4 commits into from Aug 5, 2020
Merged

Rubocop v0.87+ compatibility #179

merged 4 commits into from Aug 5, 2020

Conversation

marcandre
Copy link

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 new TreeRewriter#import feature.

cdmo added a commit to psu-libraries/psulib_blacklight that referenced this pull request Jul 9, 2020
@tomhughes tomhughes mentioned this pull request Jul 9, 2020
banukutlu pushed a commit to psu-libraries/psulib_blacklight that referenced this pull request Jul 9, 2020
* 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
@ecylmz
Copy link

ecylmz commented Jul 20, 2020

Hi,

It's been almost 2 weeks. Why is PR not merged?

@exterm
Copy link

exterm commented Jul 30, 2020

Thank you for your contribution, and sorry for not responding earlier. Shopify is dramatically cutting back on the use of erb, so maintaining erblint is not a top priority right now. We do still use it though, welcome your contribution, and will get to work reviewing it right now!

end

def diagnostics
corrector.diagnostics
if defined?(::RuboCop::Cop::Base)
Copy link

@exterm exterm Jul 30, 2020

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?

Copy link
Author

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.

Copy link
Author

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...

Copy link

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+?

Copy link
Author

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

Copy link

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.

Copy link
Author

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 👍

Copy link

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 🙂

Copy link
Author

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.

Copy link
Author

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

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?

Copy link
Author

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.

Copy link

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.

@exterm
Copy link

exterm commented Jul 30, 2020

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.

activate_team(processed_source, source, offset, code_node, build_team)
end

if ::RuboCop::Version::String.to_f >= 0.87
Copy link

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?

Copy link
Author

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.

Copy link

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.

@exterm
Copy link

exterm commented Aug 4, 2020

Thank you for structuring your changes into separate commits, makes the review so much easier 👍

end

def diagnostics
corrector.diagnostics
if ::RuboCop::Version::String.to_f >= 0.87
Copy link

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

Suggested change
if ::RuboCop::Version::String.to_f >= 0.87
if ::RuboCop::Version::STRING.to_f >= 0.87

@exterm
Copy link

exterm commented Aug 4, 2020

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

@thegedge
Copy link

thegedge commented Aug 4, 2020

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).

@marcandre
Copy link
Author

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 .travis.yml file, but yes, it is needed. I'd recommend including ruby-head too (allowed failures if need be)

@exterm
Copy link

exterm commented Aug 4, 2020

working on a setup to test both code paths in #181

@exterm
Copy link

exterm commented Aug 4, 2020

I'd love to get the CI setup figured out first, cherry-pick it over here and merge both together

@thegedge
Copy link

thegedge commented Aug 4, 2020

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 😓

@exterm exterm mentioned this pull request Aug 4, 2020
Philip Müller and others added 4 commits August 4, 2020 19:56
We want to test code paths specific to these new APIs while still also testing the old code paths for compatibility
@marcandre
Copy link
Author

Cherry-picked, all green.

Copy link

@exterm exterm left a 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!

@exterm exterm merged commit 73c9a6e into Shopify:master Aug 5, 2020
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.

None yet

4 participants