We have a large-ish Rails app that started life in Rails 5. Since then we have generally tried to keep it synchronized with the main line of development in the Rails world. For example, with Rails 7 we rewrote our JS stuff in Stimulus and started using importmaps–no small task.
In general, I think it’s a good principle to do this, to keep the state of our codebase in line with what developers will expect, rather than allowing it to take on a “legacy” feel, and thus get harder to maintain. I’m doubting this principle in the case of Propshaft though. It sounds like it could be a huge amount of work for not much gain.
Frankly, the rate of change with the front-end related aspects of Rails has been exhausting over recent versions: Sprockets, Webpacker, importmaps, Stimulus, Propshaft etc. Insofar as the shifts since Webpacker was the main thing have been simplifying, it seems like things may be settling down at last with importmaps and Propshaft, and thus that it might make sense to move in the same general direction. Is this a fair assumption?
Or perhaps the pragmatic thing to do would be to stay on Sprockets and move to Propshaft when we eventually do a front-end redesign?
Would be interested to hear people’s thoughts/experiences/opinions on this.
I’m not experienced enough to really answer, but I’ll throw out a comment anyway. Some libraries have both JS and CSS and they can more difficult to sort out. Waiting until those libraries have made more compatible with Propshaft or the workarounds have been sorted out seems like a good idea.
If it works don’t fix it! In time, others will have worked through ay issues. The workarounds that you may need will probably require changing later. Another way to decide is when you no longer see posts about how to make the transition. When Rails 9 comes out might be a good time.
Since I’m one of the maintainers of Propshaft, and someone who contributed to Sprockets so it would work correctly with the bundlings gems, I think I can answer this one with some confidence.
Propshaft was built because we wanted to simplify the codebase, and improve how some things worked (eg: you no longer need asset helpers in CSS), which would be helpful for maintainers and new projects.
But if your existing project and workflow works fine with Sprockets? It’s fine to stay on it. Wait until the next front-end redesign, or until you need something that Propshaft has that Sprockets doesn’t. Or until you have a few hours to try and make the move. I have a pretty large monolith with hundreds of CSS/javascript files that I migrated in an afternoon and most of the time was fixing asset helpers in CSS files (which you probably won’t have to worry about if you are using import-maps).