Webpacker has been retired / Upgrade frontend bundling

[Splines]

From the Webpacker Readme:

Webpacker has served the Rails community for over five years as a bridge to compiled and bundled JavaScript. This bridge is no longer needed for most people in most situations following the release of Rails 7. We now have three great default answers to JavaScript in 2021+, and thus we will no longer be evolving Webpacker in an official Rails capacity.

Finally, you can continue to use Webpacker as-is. We will continue to address security issues on the Ruby side of the gem according to the normal maintenance schedule of Rails. But we will not be updating the gem to include newer versions of the JavaScript libraries. This pertains to the v5 edition of this gem that was included by default with previous versions of Rails.

So, while we can except some more security updates in the short term, we should definitely adopt one of Rails 7 "new answers to JavaScript" in the long run, to still get security updates (in the distant future) and also new JS features.

So that's the story for JavaScript in Rails 7 and beyond. A default path with Hotwire and import maps, an alternate path using a thin integration with one of the popular JavaScript bundlers. [...]

A quote on the old Asset Pipeline (Sprockets) vs. new approaches

"The problem with Sprockets (the old assets pipeline) is that it did not integrate with front-end package distribution systems like NPM or Yarn and relied on the community to make gemified versions of these packages. If you wanted to use something that was not available as a gem you would have to download it manually or integrate Webpack or some other package manager anyways. It was pretty great back when rails was one of the only frameworks to ship with an assets pipeline but is completely obsolete today." ~ from here

Further resources

• Rails 7 will have three great answers to JavaScript in 2021+
• Rails 7 replaces Webpacker with importmapped Hotwire as default JavaScript setup
• Thinking in Hotwire: Progressive Enhancement - This has some really great examples of what Hotwire is all about
• Rails and JavaScript, Part 5

[Splines]

We should consider #421 alongside this.

[Splines]

Also consider the role of the sprockets asset packing library along the way and its interplay with webpacker. This already feels like it's going to be a big pain to migrate to the new Rails way of managing JS assets. However, it will probably help to streamline things and tidy up the frontend files we have right now (and getting rid of .coffee).

[Splines]

We should also consider the bug #468. Maybe, we can manage .css files, so they are really only applied to the partials etc. and not mingled together into one big bundle that gets applied to the whole page. That is, we should be able to use something like li { ... } in css and only affect the list items in the views that import the respective stylesheet and not every list item on any view.

[fosterfarrell9]

Let me just say in defense of the global bundling by sprockets that we use a lot of nested partials (I would guess that a "nesting level" of 5 or 6 is not uncommon), and a lot of partials are used in different contexts. I would imagine that with local styling, it could be quite challenging to keep track of what the css rules are in a given view.

[Splines]

@fosterfarrell9 Ok true, that might really be challenging, especially for all the already existing files. So, it'd be probably easier to continue using explicit CSS, e.g. #my-super-cool-div-wrapping-things .li { ... } etc.

[Splines]

Note: Also try to switch to another datetimepicker or import it in a more canonical way instead of the dirty and fragile hacks in application.js. Fixed in #526

[Splines]

Getting rid of webpacker does not necessarily mean we have to replace it by webpack (without the er at the end). While webpack was for a long time the only way to bundle for the web, we now have a plethora of options to choose from. Those are often faster than webpack: for JS files it's not a too big issue for us, but the workflow with SCSS files is really bad right now as you have to wait almost a minute (didn't measure but estimated) before the SCSS is finally bundled to see the changes.

For some alternative bundling tools, see for example this article. While I haven't used it yet, I've heard about Vite many times on the Internet. And with almost 68K GitHub stars, it's not unknown ;) It even has its own Vite Ruby off-spring, see also the Introduction and the available Rails Integration. It might be worth to check out. We just have to see if our custom webpack config can be ported to it. Also I'm not too sure how it handles the server-side rendering of the JS files with the erb syntax... In the end, it's still Rails itself that renders it, right? So it just bundles our static assets? This is to investigate...

[Splines]

In the new setup, we could also use minification and obfuscation to greatly shrink the frontend bundle sizes. Additionally, we could get rid of properties like data-cy for the frontend.

[Splines]

With Rails 8.0 (see #710), we could think about Propshaft + Vite together. See also the Sprockets -> Propshaft update guide.