I don’t think in general I’ve ever had a hard time selling it. The issue is the decision pretty much all or nothing; everyone has to be using it as well. Getting a number of people to switch is always difficult.
Locally I just delete it and use yarn for all my commands, and they can use NPM for their commands.
It doesn't make much of a difference, not actually sure what the problem is.
Nobody would even know whether you're using yarn or NPM if you don't commit a lockfile I suppose
Just like no one would think of letting their developers choose whether they want to bundle their code using either Webpack or Rollup, the package manager should really be enforced at the project level, whether you choose Yarn or npm.
But I've been doing this for years and so far haven't ran into it
I really don't have the mental energy to fight with people over package managers -- it's just not worth it.
> your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees).
If I have "express" in my package.json and do "npm install" or "yarn install" -- the functional outcome is (and always should be) the same
Unless you're using some package-manager specific behavior so that it only works properly or relies on particularities from either yarn/npm/pnpm whatnot, I'm not sure I understand how this could cause problems
But also, you're the lead maintainer of Yarn and I'm just some schmuk who's been on the consuming end for the last many years. I reckon you've got a fair bit more clue here than I do.
Commit your lockfiles. Their whole point is to reduce the risk of dependencies silently breaking your build.
If you don't run tests in your production environment (and most people don't), then you need to commit a lockfile and use it when deploying.