Loosen webdrivers constraint in solidus_dev_support

[gsmendoza]

Goal

As a solidus_starter_frontend maintainer

I would like solidus_dev_support to support webdrivers 5.0

So that when solidus_starter_frontend is installed, it won't have to revert the gem to an older version in order to support solidus_dev_support.

Expected criteria

Given I have I installed a Solidus app following the instructions from https://github.com/nebulab/solidus_starter_frontend#for-a-new-store When I check the Gemfile.lock file of the app Then I should see that webdrivers has been set to 5.0.0. When I try to install solidus_starter_frontend on top of the Solidus app (https://github.com/nebulab/solidus_starter_frontend#frontend-installation) Then I should see that it is installed successfully

Bug description

When the solidus_starter_frontend script tries to install rspec, it encounters the following error:

$ LOCATION="https://raw.githubusercontent.com/nebulab/solidus_starter_frontend/master/template.rb" bin/rails app:template

...

    generate  rspec:install
       rails  generate rspec:install
Bundler could not find compatible versions for gem "webdrivers":
  In snapshot (Gemfile.lock):
    webdrivers (= 5.0.0)

  In Gemfile:
    webdrivers

    solidus_dev_support (~> 2.5) was resolved to 2.5.1, which depends on
      webdrivers (~> 4.4)

Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.

Related

See Loosen puma and rspec-rails version constraints in solidus_dev_support for a similar issue. You can also find the commit in https://github.com/solidusio/solidus_dev_support/pull/178.

Checklist

• [x] I have structured the commits for clarity and conciseness.
• N/A: I have added relevant automated tests for this change.

[mergify[bot]]

It looks like this PR is missing a label to determine the type of change it introduces. The maintainer should add one of the following labels:

• bug for bugfixes.
• enhancement for new features and improvements.
• documentation for documentation changes.
• security for security patches.
• removed for feature removals.
• infrastructure for internal changes that should not go in the changelog.

Additionally, the maintainer may also want to add one of the following:

• breaking for breaking changes.
• deprecated for feature deprecations.

Once the correct labels have been set, simply remove the needs changelog label label from this PR so I can merge it.