Tracking Rails Main (2/2)

06 Jul 2021 . Rails . Comments #

After setting out to upgrade a large application to rails/rails main and managing to go from 5.2 to 6.1, but the process took an entire weekend and grew past a reasonable blog length. Desk is a much smaller application, with 1000 lines of ruby and 2000 lines of javascript in the app directory– the process should be 100x easier.

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 gem 'rails', github: 'rails/rails' but that throws an error looking for master. The correct Gemfile change includes the branch tag:

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 2.0

$ 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. Running 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 the first ActionCable message broadcast take down the processor. According to [this rails issue], the messages: hash is interpreted as a keyword argument in ruby 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. By tracking :main branch of rails, I’m hoping with incremental pain, it never becomes as overwhelming as Part 1.

See the changes on Github.com