There have been a lot of changes over the years in asset management 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.

Over the years, Rails has been changing the default way to handle assets while also adding different alternative options at the same time.

At first there were static files, then Sprockets appeared, then we had a choice between Webpacker and Sprockets for a few years, now Webpacker is gone and importmaps are the default. But jsbundling-rails and cssbundling-rails are also official options.

Sound confusing? In this article we’ll try to explain the history of all these changes.

We’ve come a long way as full-stack Rails engineers. We began with everything neatly bundled in one framework, handling both backend and frontend together. The asset pipeline, with Sprockets, kept this ecosystem running smoothly for us. Then, as front-end complexity grew, we turned to Webpacker to pick up where Sprockets left off.

Now, it’s time for the next step in our journey: moving from Webpacker to esbuild. In this post, we’ll explore how to make that transition and why it’s worth considering.

When we run tests, we don’t want to hit external services in most cases, so our tests don’t depend on external services and are more stable. We can use gems like VCR or WebMock to stub the requests that are done by the Rails application, but when the request is initiated by the JavaScript code… that’s a different story.

In modern apps, it’s common to enhance the user experience with JavaScript. Whether it’s just some JavaScript sprinkles here and there or a full JS-based frontend, this is as important as your Ruby code when it comes to the app’s correct functionality. In this article we’ll show how to measure the test code coverage for the JavaScript code when running system/integration tests along with the Ruby code coverage.

Back in 2011, Rails 3.1 introduced The Assets Pipeline feature using the Sprockets gem. This made it really easy to handle assets (images, fonts, JavaScript, CSS and more), solving many of the issues that developers had to face everyday.

In 2012, Webpack was released solving the same issues in a different way and in time became the most used solution to handle assets. And since Rails 6, Webpack became the default solution to handle JavaScript assets using the Webpacker gem on new Rails applications.

In this article I’ll explain the steps we took to migrate to Webpack to handle our JavaScript assets, and how we added support as a node module in our styleguide.