Interesting guide. Re-reading what I’ve written, I am not responding to this guide, per se, but to the choices made by Rails over the past few years when it comes to handling “assets”. (If I knew how to do ironic finger quotes, I would do them.)
I tried using webpacker several times over the last several years - particularly with new projects, but compared to using webpack it was a combination of “configuration: too hard”, “availability of webpack options: not good enough” and “directory naming: poor choices”.
Instead I use a hybrid approach: webpack/minipack** (not webpacker) for my work, and I let gems do their own thing, which is generally sprockets.
Now reading this guide I keep seeing “webpack: too hard”. I look at the multitude of options offered and which you should use depending on your capabilities and your type of application and it looks too hard. The hardest parts of configuring webpack have been conforming to Rails expectations of where javascripts, css, and images should live.
Import Maps looks as though it is the way to go, but then…
This [Import Maps] is a very different approach to handling javascript and css files and will require extensive work to migrate, specially if you have a lot of frontend code or rely on many node packages. … so perhaps not recommended.
Propshaft is still in alpha
…will also allow you to later webpack with the phenomenal esbuild …
There is a word missing here - I assume its “replace”.
All in all, looking at this it seems as if webpack and its successors continue to be a better path than the changing, changing, and changing again options that Rails has been offering.
I don’t have a well thought-out suggestion to offer, but I think if Rails stood back from taking decisions about frontend frameworks and let users pick the most suitable (popular/elite/easy) approach for a project, it would be better in the long run.
Anita
** Minipack, with minimal configuration, provides Rails helpers to handle webpack manifests.
