I’d love to see some guidelines on sprockets JS and Webpacker JS co-existing in older code bases, especially during a migration. I touched on this in the Big Ball of Sprockets Frustration thread and have since done a bit more digging.
As I understand it now, it’s quite feasible to leave existing (let’s call it legacy) javascript as-is, asset-packed by sprockets as it traditionally has been, and add a separate pack file for Webpacker based JS. You can then make some decisions in your layout or wherever makes sense to include one or the other (or both maybe, in weird cases).
Then all that’d be needed would be a migration path.
Specifically what I think would be a great thing to walk through in some detail is migrating some jQuery based code. I know that’s probably ancient history in Javascript terms but as a mostly back-end guy last time I checked (which seems only weeks ago but realistically was several years) jQuery based rails-ujs was the way to do things.
From what I understand the reason jQuery has receded is because ES6 more or less covers the ground it used to cover. It might well be that covering JS migration from legacy style to modern is well out of scope for Rails documentation (a reasonable perspective), but even if that’s a given I’d say some kind of structural advice might be worthwhile. Maybe something like what I laid out above - keep both pipelines working, include one or the other and consider using [external resource A, B or C] to learn to migrate your legacy JS across to modern ES6, Webpacker stuff.
edit: I didn’t feel right putting this into a pull request because I don’t actually have enough detail to write this myself. I considered a GitHub issue but didn’t want to spread the discussion across too many platforms. Happy to engage there if that’s what is preferred.