Otherwise you get the following error when starting RSpec:
```
(...)
An error occurred while loading base_spec_helper.
Failure/Error: require 'pry' unless ENV['CI']
NameError:
undefined method `=~' for class `Pry::Code'
# ./spec/base_spec_helper.rb:10:in `<top (required)>'
No examples found.
(...)
```
There were a few changes needed:
* Plugins are now specified through `plugin:` config keyword.
* All plugin gems need to be specified explicitly in Gemfile since they
are no longer dependencies of plugins already specified explicitly.
* All plugin gems need to be updated in other to use the new APIs.
* One cop was renamed.
* New offenses safe to correct were corrected directly with `bundle exec
rubocop -a`.
* New offenses unsafe to correct were added to the TODO configuration
with `bundle exec rubocop --auto-gen-config --auto-gen-only-exclude
--exclude-limit 1400 --no-auto-gen-timestamp`.
Even without it, Rails seems to do this by default:
```console
$ RAILS_ENV=production SITE_URL=foo.bar SECRET_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx bin/rails db:drop
I, [2025-10-23T12:38:12.383244 #32647] INFO -- : [dotenv] Loaded .env
I, [2025-10-23T12:38:12.383292 #32647] INFO -- : [dotenv] Loaded .env
W, [2025-10-23T12:38:12.411675 #32647] WARN -- [Bugsnag]: No valid API key has been set, notifications will not be sent
bin/rails aborted!
ActiveRecord::ProtectedEnvironmentError: You are attempting to run a destructive action against your 'production' database.
If you are sure you want to continue, run the same command with the environment variable:
DISABLE_DATABASE_ENVIRONMENT_CHECK=1
Tasks: TOP => db:drop => db:check_protected_environments
(See full trace by running task with --trace)
```
And the gem hasn't been updated in 10 years, so probably best to get rid
of it.
Rails 4.1 added time helpers but we never bothered using them. But now
I'm getting rid of the Timecop dependency and use standard helpers.
Beware though that the new helpers always freeze time. When you travel
to a certain date then the clock stops ticking while Timecop maintained
the passing of time.
The freezing of time could cause problems if you are trying to enforce a
timeout. But all current specs don't seem affected.
In most cases, the freezing will make it easier to avoid flaky specs.
The undercover docs recommended to remove it from the Gemfile but that's
only valid if you use only undercover. We do rely directly on the
simplecov gem to generate reports though.
The helpers are more convenient but also allow us to add options like
smooth scrolling. I thought that looked nicer and is less confusing.
Please note that the `scroll_into_view` helper uses the `targets`
attribute instead of `target`. That attribute needs CSS selectors with a
leading `#` for ids.
Reverting 41d56ce98b:
> This was previously included in Ruby, and has now been extracted.
> It's used by activemerchant and selenium and possibly others,
> but those gems don't currently declare it as a dependency.
This has changed. It's now a dependency of:
* activemerchant
* rubocop [dev dep only]
I ran stimulus_reflex:install. It skipped over most things, but did add gem redis-session-store without explanation. It's mentioned in the [documentation](https://docs.stimulusreflex.com/hello-world/setup.html#session-storage), but I don't think it's relevant to us so I removed it again.
It contains a fix for stimulus_reflex 3.5.0-rc4, but hasn't been released yet.
https://github.com/podia/stimulus_reflex_testing/issues/21
Now the user reflex spec works, but the products spec needs another fix. But we plan to remove it soon anyway.
I observed a significant speed-up on the second run. The first run seems
to be a lot slower though. Additional output suggests that it's now
loading the Rails environment which it doesn't do without spring.
```
time bundle exec rubocop Gemfile
0m2.496s
time rubocop Gemfile # not always right version
0m1.999s
time ./bin/rubocop Gemfile
0m7.543s
time ./bin/rubocop Gemfile
0m0.670s
```
From dotenv V3 changelog:
> The dotenv-rails gem is now superfluous. It's not technically
deprecated yet and will continue to work, but the dotenv gem does the
same thing. bkeepers/dotenv#468
Dependabot updated openid_connect despite this being restricted in our
Gemfile. Now, all future updates downgrade openid_connect again to
satisfy our requested version.
I couldn't find any good reason not to upgrade openid_connect though and
since that's the version we already have, let's keep it and just remove
the restriction. Then bundler doesn't downgrade any more and updates are
performed well.
The hiredis client was praised as being faster parsing bulk responses
but it seems to have multiple issues now:
- The redis release 5.0 moved hiredis support to another gem.
- I tried the hiredis-client gem and it raised errors.
- There are claims of worse performance of hiredis [1].
- Maintenance responsiveness has been questioned [2].
Using the default redis driver seems to work fine though.
[1]: https://discuss.rubyonrails.org/t/hiredis-does-not-support-ssl-action-cable/75945
[2]: https://github.com/redis/hiredis/issues/655
The rswag gem consists of three gem which are all maintained in the same
repository. So when one of the three gems is updated, the version of all
three gems is bumped. Dependabot was opening 3 independent pull requests
with the same release notes and linking to the same repository.
I hope that making the rswag gem a dependency will make Dependabot try
to update all gems together.
We are still listing two gems separately to be loaded in production.
They enable us to view the API documentation. But we don't need the
third gem rswag-specs in production. That one is only useful in tests.
