Upgrading to Rails 6 in 2019 and 2020

UPGRADING TO RAILS 6.1 (CURRENT RELEASE)

As always, the first step to upgrading to Rails 6.1 is to pay attention to your deprecation warnings while you are still in Rails 6.0. As well, test coverage is necessary to make sure that you won’t introduce regressions you aren’t aware of.

You now have a nifty flag to use when creating a new app –minimal.

It will leave-off a bunch of heavy weight things you might not need, like action_cable, action_mailbox, action_mailer, action_text, active_job, active_storage, bootsnap, jbuilder, spring, system_tests, turbolinks, and webpack

• Uniqueness validator will no longer enforce case sensitive comparison in Rails 6.1. To continue case sensitive comparison on the :email attribute in Target model, pass case_sensitive: true option explicitly to the uniqueness validator.

• If you’re a generator freak you now have a hook to use after you generate:

config.generators.after_generate

• The default Gemfile gets rack-mini-profiler added to it.

• Controller-level `force_ssl` will be removed from Rails 6.1. Instead you should enable `config.force_ssl` in your environment configuration to enable the ActionDispatch::SSL middleware. This allows your app more fully enforces that your application communicates over HTTPS all the time. If needed, you can use `config.ssl_options` to exempt matching endpoints from being redirected to HTTPS. Using HTTPS all the time is called “HTTPS-everywhere” and is now the default and preferred recommended way to host your website (it helps your domain’s SEO!).

force ssl shown with deprecation warning

In my IDE (RubyMine), the force_ssl appears with strikethrough to tell me this warning. If I hover over, I see

force-ssl shown with warning in IDE

• There are some structural changes to middleware, plugins.

• An introduction of a benchmark generator. Use it with:

rails generate benchmark opt_compare

I will cover benchmarking in a series later this year.

• If you have a non-standard name for “id” (that is, your primary key is called something like uuid), you can now configure this globally for ActiveRecord

config.generators do |g|
  g.orm :active_record, primary_key_type: :uuid
end

(This tells generators to use :uuid as your primary key)

Configuration files for environments (config/environments/*.rb) are now able to modify autoload_pathsautoload_once_paths, and eager_load_paths.

As a consequence, applications cannot autoload within those files. Before, they technically could, but changes in autoloaded classes or modules had no effect anyway in the configuration because reloading does not reboot.

Ways to use application code in these files:

  • Define early in the boot process a class that is not reloadable, from which the application takes configuration values that get passed to the framework.# In config/application.rb, for example. require “#{Rails.root}/lib/my_app/config” # In config/environments/development.rb, for example. config.foo = MyApp::Config.foo
  • If the class has to be reloadable, then wrap the configuration code in a to_prepare block:config.to_prepare do config.foo = MyModel.foo endThat assigns the latest MyModel.foo to config.foo when the application boots, and each time there is a reload. But whether that has an effect or not depends on the configuration point, since it is not uncommon for engines to read the application configuration during initialization and set their own state from them. That process happens only on boot, not on reloads, and if that is how config.foo worked, resetting it would have no effect in the state of the engine.

Make sure to run

rails active_storage:update

https://stackoverflow.com/questions/65499645/undefined-method-service-name-for-activestorageblob-after-upgrading-to-rails

If you fail to do this, you may get this error.