Tracking Rails Main (2/2)
Update the Gemfile
The current application is locked to
6.0.1. I will be skipping 6.1
this time and going from
6.0.1 to the main branch. The Gemfile
generated by the rail-6
rails new command recommends using
github: 'rails/rails' but that throws an error looking for
correct Gemfile change includes the
gem 'rails', github: 'rails/rails', branch: 'main'
bundle update, just like when moving from 6.0 to 6.1, bundler has a ton of
dependency errors. Unlike the other codebase, which was locked to versions,
unraveling the dependency (which turned out to be
tzinfo) was as simple
as allowing a single
'~> 1.0 to pass
$ rvm use ruby-3 $ bundle install ruby_dep-1.5.0 requires ruby version >= 2.2.5, ~> 2.2, which is incompatible with the current version, ruby 3.0.0p0 $ bundle update
The bundle didn’t work across ruby versions, but updating the bundle fixed the dependencies.
rails s returns a stack trace:
undefined method `reference' for ActiveSupport::Dependencies:Module (NoMethodError)
There’s a PR on the
devise repository that addresses the problem, so for the time
being we will reference the branch. That line ends up looking like:
gem 'devise', github: 'ghiculescu/devise', branch: 'patch-2'
That ends up fixing the pre-boot failures of our rails app, but I don’t want to leave this reference any longer than I need to. I get enough chatter in my inbox, so I set a custom notification setting for the issue. I opt-in for Merged notices to see when I can set my branch to ‘heartcombo/devise’ master and eventually a released rubygem.
I perform a yarn system update, rebuild my npm packages and relaunch rails.
A few page loads go well, and then I start my
sidekiq job processor only to have
ActionCable message broadcast take down the processor. According to
[this rails issue], the
messages: hash is interpreted as a keyword argument in
3.0.0. A couple squiggly lines later, and the processor works.
No matter how complex the application is, ruby and rails updates can be painful.
:main branch of rails, I’m hoping with incremental pain, it never
becomes as overwhelming as Part 1.
See the changes on Github.com