3 ms·

serious question, if you are starting a new project today why would you choose to use npm over yarn?

azangru 8y ago
Because npm is a standard (default) package management tool that comes with node. After getting `package-lock.json` and `npm ci`, I would rather wonder why choose yarn instead of npm.
- MehdiHK 8y ago
  "npm ci" deletes node_modules directory every time. Try using that when you depend on some native modules. :(
  - azangru 8y ago
    I thought `npm ci` is more suited for ci machines, where it's crucial that packages are pinned to specific versions. For local development, I just npm install. Perhaps with no-save option in order to avoid updating package-lock. Works fine.
- eknkc 8y ago
  Because I don’t trust it. Had to do rm -rf node_modules too many times with npm.
ariabuckles 8y ago
Because it comes standard with most node distributions and is pretty good. It coming standard means one fewer dependency for everyone on the team to install, which is important on my current team where roughly half are backend- or mobile-only. I like both yarn and npm, and yarn would have some benefits for us, but probably not enough to counter the extra effort onboarding other devs. npm still has some pain points, but I’ve ran into a few pain points on yarn too. And I think there being multiple projects here has helped the ecosystem. npm is also doing some neat feature development (npm audit). Also, the npm team is fantastic, whereas when I adopted yarn early on they dismissed the issue I opened about yarn not working for my setup. They’re a good team, but that lowered my confidence that I’d be able to get through any obstacles while using it. It’s still a fantastic tool though.)
asnrk 8y ago
Experience at the agency I worked at until a couple months ago, which had continually followed this pattern with projects started after the yarn/npm split got serious: 1) Start or inherit a project using Yarn because that's what all the cool kids are using. 2) Develop for a while, everything's fine. 3) Lose a whole day when you eventually stumble on a Yarn bug or missing feature in Yarn. 4) Angrily switch the project to NPM, solving the problem immediately. 5) Continue developing as usual. I think this happened on like half a dozen projects after the yarn/npm split occurred, and I saw it happen as recently as Fall 2018. Developers leaned trend-chasing there, but after being burned several times even the trend-chasier ones were tepid on yarn and tended to accept that if they started with it they'd probably end up switching before long. FWIW I don't like npm much, but I still default to it so I don't, inevitably, hit the above situation at some point. Yarn doesn't provide enough benefits to make it worth having an even less-trustworthy tool in my build process than npm already is. [EDIT] TL;DR: We all got sick of ending up on open GH issues for Yarn when trying to track down build and, worse still, run-time problems. So we started favoring NPM again as the lower (though far from zero) headache option.

Because npm is a standard (default) package management tool that comes with node. After getting `package-lock.json` and `npm ci`, I would rather wonder why choose yarn instead of npm.

MehdiHK 8y ago
"npm ci" deletes node_modules directory every time. Try using that when you depend on some native modules. :(
- azangru 8y ago
  I thought `npm ci` is more suited for ci machines, where it's crucial that packages are pinned to specific versions. For local development, I just npm install. Perhaps with no-save option in order to avoid updating package-lock. Works fine.
eknkc 8y ago
Because I don’t trust it. Had to do rm -rf node_modules too many times with npm.

ariabuckles 8y ago

Because it comes standard with most node distributions and is pretty good. It coming standard means one fewer dependency for everyone on the team to install, which is important on my current team where roughly half are backend- or mobile-only. I like both yarn and npm, and yarn would have some benefits for us, but probably not enough to counter the extra effort onboarding other devs. npm still has some pain points, but I’ve ran into a few pain points on yarn too. And I think there being multiple projects here has helped the ecosystem. npm is also doing some neat feature development (npm audit). Also, the npm team is fantastic, whereas when I adopted yarn early on they dismissed the issue I opened about yarn not working for my setup. They’re a good team, but that lowered my confidence that I’d be able to get through any obstacles while using it. It’s still a fantastic tool though.)

asnrk 8y ago

Experience at the agency I worked at until a couple months ago, which had continually followed this pattern with projects started after the yarn/npm split got serious: 1) Start or inherit a project using Yarn because that's what all the cool kids are using. 2) Develop for a while, everything's fine. 3) Lose a whole day when you eventually stumble on a Yarn bug or missing feature in Yarn. 4) Angrily switch the project to NPM, solving the problem immediately. 5) Continue developing as usual. I think this happened on like half a dozen projects after the yarn/npm split occurred, and I saw it happen as recently as Fall 2018. Developers leaned trend-chasing there, but after being burned several times even the trend-chasier ones were tepid on yarn and tended to accept that if they started with it they'd probably end up switching before long. FWIW I don't like npm much, but I still default to it so I don't, inevitably, hit the above situation at some point. Yarn doesn't provide enough benefits to make it worth having an even less-trustworthy tool in my build process than npm already is. [EDIT] TL;DR: We all got sick of ending up on open GH issues for Yarn when trying to track down build and, worse still, run-time problems. So we started favoring NPM again as the lower (though far from zero) headache option.