Rails 5.2+: why still use assets pipeline with webpacker?

Question

I was reading the Rails webpacker gem documentation where it says:

Webpacker makes it easy to use the JavaScript pre-processor and bundler webpack 4.x.x+ to manage application-like JavaScript in Rails. It coexists with the asset pipeline, as the primary purpose for webpack is app-like JavaScript, not images, CSS, or even JavaScript Sprinkles (that all continues to live in app/assets).

However, it is possible to use Webpacker for CSS, images and fonts assets as well, in which case you may not even need the asset pipeline. This is mostly relevant when exclusively using component-based JavaScript frameworks.

I'm trying to understand the rationale behind using both the older assets pipeline for CSS/images/JS-sprinkles if webpacker is capable of handling all of this?

I've read some other articles that walk me through using webpacker for all of this, but I don't understand the reasoning behind this decision.

Is this just to support legacy applications and eventually the older assets pipeline will go away and webpacker will be used for everything in Rails apps?

Answer 1

As a maintainer of an app that existed before Webpacker, I can give you one reason:

It's hard to migrate an existing frontend from Sprockets to Webpack.

Sprockets builds all JS into one big file with shared scope. Webpack isolates the scope of every JS module. To migrate to Webpack, you need to make sure your code still works with the scope isolation.

Which is often problematic, because in the Sprockets times you didn't have proper JS requires, either, and had to rely on globals or top-scope variables to share code and data between your JS source files.

Rails doesn't offer a painless transition path from Sprockets compilation to Webpack. So, it must support both.

But to answer your other question - going forward, you should use Webpacker if you have enough JS to make it worthwhile .

If your frontend is simple, you will skip some JS nuisances if you use Sprockets. Like if you want to add 10 lines of JS to your app, you might not want to setup a whole JS environment with dependency management and node_modules etc - which is the price of using Webpack/Webpacker. It would be even more senseless to manage a JS environment if all you want is to compile CSS and add digests to your image filenames - which Sprockets is perfectly capable of, without a package.json and anything else JS related.

Therefore, there's a second reason:

Webpacker is good for apps that have a significant frontend codebase. Sprockets is good for adding a bit of JavaScript to a traditional server-rendered app, and for apps with no JavaScript at all.