We moved all assets into the webpacker directory to manage it there. I reckon that we should revert that one by one and tackle the Javascript part last. We will be reverting a lot of this pull request:

• Webpacker assets #7784

It has 51 commits and many of them deal with individual packages like Foundation and jQuery. It may be useful to have a hybrid system for a while. I picked relevant commits here in reverse order to act on:

• 1ff75ee fonts
• aa6a492 images
• 63f6567 images
• 2888d75 images
• 12f51fe images
• 31276ff images & fonts
• a11aebb css
• 90956c9 css
• a55c38c select2
• 0e4d77a select2
• 80be57a select2
• a38d495 images
• 5bc02d1 font-awesome
• 6f06205 css
• ba583dc jquery-ui
• 9d18f31 css
• b33ac49 autocomplete, leaflet
• 0057dbc autocomplete, leaflet
• 2e194ac foundation js
• 825aeea css, images
• cb27081 foundation
• 8dfc304 css

From the article, there are three alternatives:

1. importmap-rails the default approach that will be used on Rails 7.
2. jsbundling-rails

If you're on Webpacker today, it's a very modest jump to switch to one of the bundlers made available through the jsbundling-rails gem. You don't even have to stick with Webpack. Fundamentally, they all work in the same way: take an entry point, produce a build. We've initially taken that path with Basecamp 3, converting from Webpacker to esbuild. But with HEY, we took the full step of going straight to import maps. Neither choice involved a lot of effort. The JavaScript is still the JavaScript. You're mostly adjusting a few import paths.

3. Separate the backend (Rails API) and the frontend ( I don't think that this is an option for us since we are moving to stimulus)

From what I can see, the first approach will be the best fit when AngularJs will be removed.

In the meantime, while it's still possible to use the first on the presence on AngularJS, I'm not sure if we should use jsbundling-rails.

jsbundling-rails seems to be closer to what we do at the moment. So I would start there. We do have JS templates which contain Ruby code. And I believe, but I may be wrong, that importmaps-rails doesn't support this mix.

How about using shakapaker?
@openfoodfoundation/developers

How about using shakapaker?

Yes, that would be the easiest path forward for now because it offers backwards-compatibility with webpacker. Long-term, I would like to get closer to the original Rails asset pipeline with sprockets and importmap. Default packages are often better maintained and tested. And Rails usually picks very good defaults which are still quite simple and robust while offering everything you need.

Anyway, if we can't jump straight back to the defaults then we should transition to Shakapacker for now.