Rails 5 is out! Rails 5 contains hundreds of changes, including new major features like ActionCable, but for the most part, is a drop-in upgrade for existing Rails 4 applications.

The Rails team has provided a fairly comprehensive upgrade guide, but there are some potential upgrade problems that aren’t fully covered.

Autoload vs. Eager Load in production

With Rails 5, autoloading is now completely disabled if config.eager_load = true. What this means is that if file paths outside of app/ are in your config.autoload_paths and not in config.eager_load_paths (for example, lib/), these files will no longer load in deployed environments.

This bit me on a recent Rails 5 upgrade because as config.eager_load = false is set in the development and test environments, the test suite was green and the app worked great in development mode. It was only after I deployed the application that problems cropped up, and the code in lib/ was no longer available to the application.

To test if this is the same with your app, temporarily set config.eager_load = true in config/application.rb and run the application and its test suite. If you get uninitialized constant errors there are three possible solutions.

Add to eager_load_paths

Adding the non-app directories to config.eager_load_paths will fix this problem, but this comes with an important caveat: every Ruby file in these directories will get loaded when the application boots. In my application, lib was also doubling as a vendor location for a number of external libraries and tools, which led to the application trying to load Ruby files in these tools, which in turn resulted in strange errors regarding missing requires and dependencies.

Re-enable Autoload

Alternatively, you can re-enable the autoload functionality for all environments:

config.enable_dependency_loading = true

This will take the application back to the Rails 4 way of “eager_load with autoload fallback”, but do note that this option may eventually itself get deprecated and removed in later versions of Rails.

Move code into app/

A better solution is to move all code the application requires into the app/ directory. Every directory directly under app/ is automatically eager and auto-loaded by Rails, reducing any external custom configuration you may need. I ended up moving the important files in lib to live under app/lib which solved all of my problems.

New Deprecation warnings

A new major version of Rails means a new set of deprecation warnings! Rails 5 is the first version of Rails to require Ruby 2.2.2 or later because of one main feature: keyword arguments. Rails APIs are slowly moving over to make heavy use of keyword arguments, and the first major spam of deprecation warnings related to this change can be found in controller tests.

Controller Tests

There are two important changes to Rails controller testing:

assert_template

If your test suite uses assert_template, or expect(response).to render_template(), this assertion has been moved out of Rails core and is now available via the gem rails-controller-testing. In case of rspec, you’ll need to upgrade rspec-rails to at least version 3.5.0.

get, post, put, delete

These testing methods will spam test output with deprecation warnings regarding the change to keyword arguments. Where these methods have long been used with multiple ordinal arguments (get(path, params, session, headers)), these params after path are now expected to be keyword arguments instead: get(path, params: {}, session: {}, headers: {}).

Depending on how many controller tests are in your test suite, this could be an annoying change, but as a huge fan of keyword arguments, and given how many times I’ve asked “How do I send custom headers into get?!”, this is a very welcome improvement that will make these tests easier to write and read.