npm has eroded so much of my trust that I am hesitant to switch back to it any time soon.
I've tried npm out every few months (since npm 3), and have consistently run into infuriating bugs or unexpected behaviors.
Much of it has been fixed over time, but the frequency and duration of these issues is concerning—and, I think, points to architectural deficiencies being the root of the problem. (And the project is so massive that it's understandably a really challenging thing to manage and triage)
* If you have OS-specific optional dependencies (Mac-only fsevents being a popular one, used by tools like webpack and watchify to massively speed up rebuilds on Mac), then if you run `npm install` on an OS that doesn't support them, then they get removed from package-lock.json. Then when the Mac user pulls the changed package-lock.json and reinstalls dependencies, fsevents isn't installed, and webpack and watchify fall back to a very slow path for watching for file changes. https://github.com/npm/npm/issues/17722
* Whenever I, a coworker, or our CI system pulls changes, we need to make sure that we have the correct dependencies installed because package.json or the lockfile may have been updated. We don't necessarily know if anyone else has changed package.json; we just want to run a command that makes sure node_modules matched the package.json and lockfile. Running `yarn` when there are no changes to package.json takes under a second, so it's easy to just always get in the habit of running, and doesn't slow down CI. We can make our build and deploy scripts just run `yarn` to be on the safe side because it's so cheap to run. But with npm, running `npm install` when there are no changes to package.json in a big project still often takes 10-30 seconds.
* I've run into many bugs like this one with npm: https://github.com/npm/npm/issues/19839. For a while, I actually made our deploy script run `npm install` in a loop until it stopped changing things just to be sure it successfully installed everything (but then it turns out running `npm install` multiple times can actually cause issues! https://github.com/npm/npm/issues/18084. To work around that, if you pull changes that include a change to package.json, you have to remove node_modules and then run `npm install`. This made our CI system so slow...). I've reported various bugs like this. The bugs would get no attention, but sometimes they'd mysteriously go away after a few versions. But bugs that go away on their own tend to come back on their own in my experience.
Yarn has only given me one issue in my use of it and it was promptly fixed. I swear by it now.
Much of it has been fixed over time, but the frequency and duration of these issues is concerning—and, I think, points to architectural deficiencies being the root of the problem. (And the project is so massive that it's understandably a really challenging thing to manage and triage)
For example:
* npm 5.0.0—5.7.0 didn't play nice with git-based dependencies (https://github.com/npm/npm/issues/17379)
* npm 5.0.0—5.4.1 edits package-lock.json unexpectedly (https://github.com/npm/npm/issues/17979)
* npm 5.0.0—5.4.? doesn't honor incompatible version differences in package.json compared to package-lock.json (https://github.com/npm/npm/issues/16866)
* Take a look at the issues labeled as [big-bug], and how long they've languished (mostly from the v3 era): https://github.com/npm/npm/issues?q=is%3Aissue+is%3Aopen+sor....
* and a bunch of others I can't remember off the top of my head; especially nondeterministic behavior in the v2 and v3 era.