3 ms·

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

by xzel 5y ago

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.

gavinray 5y ago
I've had repos where coworkers refused to use yarn, and would commit NPM's lock file 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
- arcatek 5y ago
  Note that we don't recommend using both Yarn and npm: both have different feature sets, heuristics, and implementation details, and as a result your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees). 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.
  - gavinray 5y ago
    I understand that there are probably some weird edge cases where this could cause an issue 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). Yarn and NPM both take a "package.json" and install the dependencies so that you can import them though. 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.
- smt88 5y ago
  Your team's practice of failing to commit lockfiles is risky and (as far as I know) uncommon. 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.

by xzel 5y ago

gavinray 5y ago

I've had repos where coworkers refused to use yarn, and would commit NPM's lock file 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

arcatek 5y ago
Note that we don't recommend using both Yarn and npm: both have different feature sets, heuristics, and implementation details, and as a result your colleagues and you may have slightly different behaviors in development (on top of desync'd dependency trees). 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.
- gavinray 5y ago
  I understand that there are probably some weird edge cases where this could cause an issue 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). Yarn and NPM both take a "package.json" and install the dependencies so that you can import them though. 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.
smt88 5y ago
Your team's practice of failing to commit lockfiles is risky and (as far as I know) uncommon. 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.