Webpacker has been retired

[joeroe]

See https://github.com/rails/webpacker

[joeroe]

So I spent today trying out the new importmap system (https://github.com/rails/importmap-rails/). It is very nice and I think could greatly simplify our JS pipeline. It also goes hand-in-hand with Turbo (https://turbo.hotwired.dev/) and Stimulus (https://stimulus.hotwired.dev/), which if we adopted would allow us to drop some old/heavy dependencies (e.g. jquery!) and tidy up our Javascript modules significantly.

That said, in the end I gave up trying to get all three to work with Rails 6. I don't really know what the problem is but suspect it's something to do with having importmaps running alongside webpacker at the same time. Long story short: I would suggest upgrading to Rails 7 first, then switching webpacker -> importmap, jquery -> stimulus, our JS modules -> stimulus controllers, and CSS dependencies -> (gems? cssbundling?) all at once.

[MartinHinz]

That makes perfect sense to me. I had also experimented a bit, and from experience I can only confirm the assessment. Which of us should take responsibility for this? Have you immersed yourself in it to the extent that it can be done quickly for you, or can I take on this task (but not until the end of next week at the earliest)?

[joeroe]

Not quickly... but it would be nice to do it in my data entry branch, since I'm writing a fair bit of JS and it would help to have it cleanly organised as Stimulus controllers. But the main thing I'm not confident about is the upgrade to Rails 7: maybe you could do that, then I'll merge it into my branch and do the migration to importmaps etc.?

[joeroe]

A new alternative is shakapacker (which wraps newer versions of webpack for rails): https://github.com/shakacode/shakapacker

The migration process looks... unpleasant.

[joeroe]

Useful discussion of webpacker alternatives: decidim/decidim#8783

[joeroe]

#305 replaced webpacker (and sprockets) with propshaft + jsbundling + esbuild + cssbundling.