I feel like I run into these errors all the time, but not for reasons I understand…and I don’t want disable the checks either because they exist for a useful purpose. So it’s hard to tell if this is a real bug or I’m just missing some aspect of this. (Also was seeing related grumblings in the recent Twitter threads.)
Bonus request: would love to see it get easier to use Webpacker with Rails engines…the existing docs sort of describe what can be done but there are all sorts of edge cases I’ve had to account for when composing gem packs and main app packs together in various layouts.
This is especially true if you’re using Docker with a mounted volume! It seems like everyone’s suggestion is to disable it. That can’t be a good answer, right?
The underlying problem got worse because Webpacker 5.1 disabled the checks. Now things fail silently if you switch your Git branch to a yarn.lock state which is out of sync with your node_modules folder. And we will have ways to solve this with Yarn 2 (see Webpacker issue).
I think part of the root usability issue might be the mismatch between the ways that npm and Bundler handle dependency resolution & loading. I would expect the average Rails developer to have a reasonable understanding of how Bundler models the problem (only one version can be loaded). I wouldn’t necessarily expect them to understand npm’s model (load as many versions as you want), understand that it’s different, understand the ways that Yarn 1 and npm are interlinked but distinct…
When cross-branch dependency mismatch problems crop up between different gems, you get a fast failure, it’s easy to understand how you got there, and easy to fix. So you roll your eyes, run bundle again, and move on with your life. But yarn integrity checks take a while (a visible while, even), understanding how you got there is just that little more difficult, and understanding how to fix them is also just that little more difficult. So it feels like a WTF rather than something routine.
@petrik can you go more into what you mean by a commandline actionable error, and how you feel it would solve the usability problem here? I think I understand what you mean, but I’d like it if people casually reading this thread could read a direct description here rather than following a link and needing to figure out the implied UX.
What I mean is instead of having the Yarn integrity check cause an error, and requiring a user to run yarn update, we could allow the user to interact with a prompt:
Yarn integrity check failed.
Do you want to run yarn update?
When the user answers “yes” let rails run yarn update, otherwise skip the integrity check.
