Fix backward compatibility for Bundler versions < 2.2.17 #3152
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Hi!
One of the projects that I'm working with still uses Bundler version
2.1.4
(sad, I know!) and Ruby LSP errors out upon initialization with this version. In fact, it won't be able to initialize with any Bundler prior to version2.2.17
(more details in Implementation section)!I believe that Ruby LSP is now an essential part of any VS Code's Ruby project and I want to make it backward compatible with previous versions of Bundler so that people don't have to switch to other editors/IDEs when they can't simply upgrade to newer version of Bundler due to certain project limitations.
Luckily, the fix is not that complicated!
Implementation
Let's take a look at the PR that introduced the usage of
Bundler::Settings.key_for(e)
in Ruby LSP: #2535.It might look okay at first until you realize that
def self.key_for(key)
forBundler::Settings
was only introduced in bundler-v2.2.17, meaning thatBundler::Settings.key_for(e)
won't work for any Bundler version < 2.2.17.Considering that instance method
def key_for(key)
is still in place in latest Bundler version and don't seem to be going away - I suggest we use it instead! Plus we already have an instance ofBundler::Settings
available in our local variable settings.I was also thinking about an explicit Bundler version check approach but didn't find any benefits. There's even a drawback - we'd be missing out the caching mechanism (introduced by this PR) that instance method provides in newer versions of Bundler if we keep using the class method instead.
Automated Tests
I updated corresponding
test/setup_bundler_test.rb
.Manual Tests
Actual result:
Attaching an error example that is currently happening: undefined_method_key_for_for_Bundler_Settings_Class_NoMethodError.txt.
Expected Result: