* 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.

Even the latest version of npm 6 can get dependency resolution wrong. Like, the basic core feature.

Not that this is a showstopper, but I have issues with the package-lock.json file where the `resolved` field (the package's registry URL) constantly flip flops between http and https protocols, depending on which machine I'm on (home, work, or docker container), whenever I run `npm install`. Sounds not so bad, but it becomes a mess in git, and causes any docker build caches to become invalidated.

Recently bumped into https://npm.community/t/packages-with-peerdependencies-are-i... The attitude towards fixing issues ("we won’t be able to fix until we get through an upcoming tree builder rewrite.", yeah right...) is making me want to check out alternatives

One thing that comes to mind is the lockfile not actually acting as a lockfile.

Running ‘npm install’ updates the lockfile :/

Then there was the issue where it didn’t respect git commit hashes that were added to the lockfile, just taking whatever the latest commit was.

We switched around June last year to yarn because git URL dependencies on branches was broken in npm. It would choose incorrect commit ids inexplicably. Beyond that dependency upgrade time is faster.

Just moved to Yarn this weekend strictly because npm link (used to link to a local version of a package) doesn't work the way I want it to.

Everytime I install a new package my previous `npm link` references break in the node_modules folder. `yarn link` keeps these reference. Just as I expect.