Navigating Asset Management Madness; Rails 3.0 -> Rails 7 and Beyond

There have been a lot of changes over the years in asset management opens a new window for Ruby on Rails applications. The main question, after all the madness, is… “What should I do if I need to upgrade my Rails application?”

In this article we will talk about the options we have for each version jump.

Before we start, it’s important to keep one thing in mind: changing to a new asset manager is not necessarily needed unless the manager being used is incompatible with the Rails version we are upgrading to. So far this has not happened, but it could occur in the future.

Upgrading the Rails version often enables you to change to a different asset manager. It is often the case that you can keep the current one without changing much. However, this could lead to you missing out on new features.

Here is a handy chart to give you an idea of the changes over the years.

Rails 3.0 => 3.1

There is no doubt. You can continue using static assets forever, but we recommend migrating to the Asset Pipeline using Sprockets opens a new window .

Even if you don’t need any specific new features, the benefits clearly outweigh the costs. It does not require a big change to your assets; move the files to app/assets, add the main application.* files, and configure Sprockets.

With this change, some of the benefits you will get include:

• Minification of assets
• File compression
• Digest/fingerprinting in the names to avoid caching issues
• Bundling of assets to reduce the number of requests

Between Rails 3.1 and 5.0

Sprockets is the only available option for all these Rails versions (unless you are still using static assets), so there’s nothing else to do.

You can continue updating Sprockets to add new features, bug fixes, and to support new versions of Rails, but the asset management doesn’t change.

When updating Sprockets you may need to do some specific steps to go from 3 to 4, but you don’t need to migrate to another tool.

Rails 5.0 => 5.1

Optional support for Webpack opens a new window is added with the Webpacker opens a new window gem but you don’t have to migrate to it if you don’t need the features it provides.

If you don’t know if you need its features, you can check out our article comparing Sprockets and Webpacker opens a new window .

If you decide to use Webpacker, we can help with the migration opens a new window .

If you plan to go all-in and use Webpacker to manage both JavaScript and all your other assets, we have an article opens a new window on that too.

Given the current status of the Asset Pipeline in Rails 7, we would advise NOT moving to Webpacker unless you really need the features now and you are not planning to upgrade to Rails 6.0 anytime soon, since Rails 6.0 provides more options.

Rails 5.2 => 6.0

At this point, you are probably either using Sprockets or Webpacker:

• If you are using Sprockets, you don’t have to migrate to Webpacker. Rails 6.0 made Webpacker the default for new applications but it’s not a requirement.
• If you decide to move to Webpacker, check the previous section to learn more about it.

We also have some new options available. The asset management gems released for Rails 7 are currently also compatible with Rails 6.

You can migrate to using the importmaps feature with the importmaps-rails gem opens a new window . You could also migrate to another JS bundler (like Webpack or esbuild) using the jsbundling-rails gem opens a new window , and you can also use a different CSS bundler (like Dart-sass) with the cssbundling-rails gem opens a new window .

Similar to the migration to Webpacker explained in the 5.0 to 5.1 section, you don’t need to migrate to any of the new tools. You can continue using Sprockets or Webpacker.

Webpacker was retired for the Rails 7.0 release but it’s still compatible with Rails 5.1 to 7.0 (we also tested it in our applications using Rails’ main branch and it still works just fine for Rails 7.1).

Migrating to those new tools is up to you, our recommendation is to only change if you have a good reason to.

Rails 6.1 => 7.0

Rails 7.0 changed the default for new applications to be importmaps but this does not affect existing applications being upgraded to Rails 7.0.

You can still use Webpacker (it was retired but it is still compatible with Rails 7).

You can also continue using Sprockets if you haven’t replaced it, though you’ll have to explicitly add the sprockets-rails gem in your Gemfile since it’s not included by default anymore opens a new window .

Similar to the previous section, you don’t have to migrate to the new options if you don’t have a need.

After Rails 7.0

At this point you are using either Sprockets, Webpacker, or any of the new gems.

Since Webpacker was retired, you will eventually have to migrate to another tool that is maintained to ensure compatibility with future Rails versions (it seems to work fine with Rails 7.1, but we don’t know what will happen in the future) and new standards.

There are a few options:

• Replace Webpacker with Shakapacker opens a new window .

This is a fork of Webpacker maintained by the community in active development.

This is the simplest solution, aiming to be a direct replacement of Webpacker without needing any extra change.

• Migrate to any of the jsbundling-rails options.

If you are using Webpacker you might want to use the Webpack option, since it will require the least amount of changes, but you could also take the opportunity to migrate to esbuild opens a new window to improve the asset compilation speed.

• Move back to Sprockets.

You can use Sprockets just fine in Rails 7 to handle both css and js files.

• Migrate to the importmaps-rails gem.

This option requires a lot of work and we only recommend this if you know what you are doing and you know that the tools you need are compatible with it.

In some cases, this is not a viable option (if you need to compile TypeScript or Vue files for example, importmaps does not precompile assets).

In other cases, you’ll have to change your JavaScript code to support all the browsers (Safari currently requires a polyfill for this feature and some document “load” events don’t trigger at the same time as before).

Conclusion

When we take a moment to unravel the complicated changes that have occurred over time for Rails asset management we can see that most of the time we can actually stick with what we are currently using.

However, if you want to take advantage of new features or performance enhancements it might be in your best interests to migrate. It’s best to think a few steps into the future when making a decision.

Are you migrating past Rails 6.0 eventually? It’s probably best to not migrate to Webpacker. Are you starting a new application on Rails 7? Using importmaps is a simple option with no build step but jsbundling-rails gives access to bundlers.

Always take the time to evaluate your future plans before beginning a migration that you may not need to do.

In the context of an upgrade, you can finish the upgrade, deploy it to production, and have time to think about this change. The changes in asset management don’t need to be a blocker to your Ruby or Rails upgrades.

If you have decided that you do want to migrate, but don’t have the time, we can help opens a new window !