Issue loading images from dfm_web manifest.js in Rails 6 with Webpacker

[yengfinity]

It seems like rails engines is still the forgotten child of the Rails 6 with Webpacker. After I installed and ran my app as host (rails 6 with default Webpacker), I encountered this issue after adding dfm_web's gem and followed the installation directions:

This makes sense because the _nav.html.erb parital is trying to load the uwcrest.png image from the engine and can't load any assets to the host app. To fix this at the moment and probably the fastest way for now, I added what the error message suggested to the host app's manifest.js file:

//= link dfm_web/uwcrest.png

This is redundant because that is what the engine's manifest.js file is suppose to do, however webpacker doesn't want to play nice at the moment like Jacob mentioned here: #74 . There are a few ways that this can be handled at the moment but probably not the best being that we don't know where webpacker/sprocket is taking us:

1. Covert all the engine's assets to the webpacker environment (loading them via the javascript/pack)
2. Add webpacker to the engine where it'll generate public assets that'll work nicely with webpacker and load them on the host side.

I feel that Webpacker only makes sense for front-end heavy applications (i.e React, Angular, Vue...) which require a lot of javascript and not so much css/images. So being that the engine only have one javascript file, the first choice is off the table. Choice number two is good for now to have a good mix of sprocket and webpacker, but it requires more changes to the engine.

The host app is running on Rails 6.1.4.1, Ruby 2.7.4, Sprocket 4.0.2 and Webpacker 5.4.3

[duffyjp]

Hi Yeng! Good to hear from you!

When I opened #74 two years ago now, Webpacker was so green it was wasn't even in the Rails Guides. It is now, but as they mention it has no Rails Engine support at all. 🤷 Not great news for dfm_web, that's for sure.

The other Rails devs I've been working and talking with lately have also expressed frustration with the complexity Webpack adds to what used to be a very straight-forward process.

DHH wrote about this and his vision for the future of asset management with Rails 7. Webpacker will still be on the table, but the alternatives (good old sprockets and esbuild) both feel more Rails to me.

Since we never ended up shipping a single Rails app with Webpacker here, I'm planning to just leap-frog it and skip it entirely. I'm leaning towards esbuild. It looks great, you hook in javascript compiling and it dumps it into app/assets/builds and from there it should work just like the old asset pipeline. CSS gets a similar treatment with sass or tailwind or whatever you want to use.

I'll be taking a stab at this when Rails 7 is released. Hopefully things smooth back out. There's a GoRails video on this that's pretty good. He uses lots of hotwire/stimulus stuff which complicates things, but I'm betting the workarounds he uses won't be needed by the full release.

[duffyjp]

I've been doing some work on here lately, and with Rails 7.0.1 using esbuild and sass everything seems to work really smoothly. I also rewrote the javascript in ES6 instead of jQuery so that's no longer a requirement.

Webpacker on Rails 7 will still be an issue, but if you REALLY need it, you should be able to just clone the entire repo into /vendor/dfm_web on your app and adjust paths to use that.

If you try out Rails 7 and it's not working, make sure you do bin/dev instead of bin/rails s to start the server. That fires up the new JS and CSS watchers that rebuild things on change.

I haven't done anything Rails 7 in production yet, I'll update the README if there are any gotchas when the time comes.