Thanks for inviting this kind of feedback.
Webpacker succesfully makes using modern JS toolchains in Rails way easier than before Webpacker existed.
But it is still really confusing. Some specific issues:
- The Guides still don’t mention webpacker at all as far as I know. The Guides have been a really awesome reference to figuring out Rails and Rails best practices (I see the audience being someone who is already a developer and familiar with the Web, just not with Rails). But they have not been changed at all with the introduction of Webpacker. There is still an Assets guide implying/suggesting you use sprockets for JS, and I believe following it’s instructions would actually not work in a default
rails new
rails 6. The guides were not updated for Rails 6 asset compilation defaults changed, and they need to be, not just perfunctorily, but actually giving a good overview/introduction of what’s going on, doing what the Guides do well not just barely accurately. Since this has become an even more confusing topic, it needs more, not less, Guide attention.
.
- I’m quite worried about the potential for really confusing hard to diagnose errors due to dropping yarn integrity check per Remove yarn integrity check by rossta · Pull Request #2518 · rails/webpacker · GitHub
.
- The sprockets 3 to 4 migration is still REALLY CONFUSING. Rails generating a
./app/assets/config/manifest.js
for a long time now, but this file is ignored until you are using sprockets 4 (which was only released recently), and then once your sprockets is using the manifest.js, the one Rails generated has quite different defaults than sprockets 3 had (and also depends on if it was generated in rails 4, 5, or 6, although it’s only used in all cases if sprockets 4). I contributed docs to try and explain what’s going on, but the whole situation is really confusing – before you wrap your head around it, you can start thinking you’re going crazy and sprockets is behaving non-deterministically, because things you weren’t expecting effect how it behaves.- Here is one sort of issue it often results in
- schneems, sprockets maintainer, valiantly tried to get Rails to make this less confusing, but Rails team rejected it, to me inexplicably. Use link instead of link_directory in manifest by schneems · Pull Request #28430 · rails/rails · GitHub
- It has been reported again by other users as a bug, showing how confusing it is, for instance here, with no attention
- However, at this point – I’m honestly not sure what should be done. Changing behavior AGAIN to make yet another fork (if you have a manifest.js generated by Rails 6.1, then it will be default yet different again) may not be the right solution at this point. I think some real mistakes were made in the past, but they can’t be changed at this point, I’m not totally sure what should be done now, I think some real thought has to be given to what’s the right solution – yes, I am posting a problem for which I’m not sure what the right solution is, better brains than mine may have ideas! But on the topic of “WTF things that really have stymied you”, this is one of them.
.
- sprockets 4, which gave me lots of pain, my motivation for trying it was better support for source maps, but I was unpleased to see that if you use SCSS (which is quite popular, right?), the source maps are still broken, it actually seems to make identification of where a line of css source code came from worse than it was in sprockets 3, unless you disable CSS source maps. sprockets 4 makes Chrome browser identification of SCSS css lines _worse_ · Issue #656 · rails/sprockets · GitHub