5 ms·

Am I the only one that after doing Node.js for ~10 years never had much issues with npm or a need for yarn? Yes, if memory serves me right, yarn might've been

Am I the only one that after doing Node.js for ~10 years never had much issues with npm or a need for yarn? Yes, if memory serves me right, yarn might've been first with `yarn.lock` before `package-lock.json` was a thing. But why would I use yarn today? I don't care about speed of npm install locally, I do it once in a blue moon. I don't care if my pipeline takes 3 minutes (yarn) to install dependencies instead of 5 minutes (npm).

gryn 3y ago
the reason to try yarn for me was berry pnp to avoid those pesky node_module folders but alas the experience has been bumpy on personal projects. for something that has promised more robustness, it has been anything but that. I still like the yarn cli more than the npm one, but I ended up just defaulting to npm.
lucideer 3y ago
> But why would I use yarn today? I think many many many people switched to Yarn 1.x wholesale and then switched back to NPM once it had undergone some improvements.
- leptons 3y ago
  That's me. But for some projects I've had to switch back to yarn, because npm no longer works to install node_modules, and I don't really care why. Yarn works on those projects, npm does not. If npm works for a project, I use that, but there are some where yarn works and npm simply errors and quits.
- spankalee 3y ago
  This is exactly what I did. I even participated in the Yarn project a bit before it was fully open, but as npm 6 and 7 brought major speed improvements, workspaces, and overrides, I don't see the need for an alternate package manager anymore. As a library maintainer using the same package manager that most of my users do is a pretty big help. I'll be very happy when npm's linked install strategy is stable so that there's less reason to use pnpm and we get dependency isolation in monorepos.
  - bhouston 3y ago
    > I don't see the need for an alternate package manager anymore. I do see a strong need for lerna though. Lerna's ability to manage concurrency, topological sort-based builds and streaming builds is phenomenal and an absolute necessity in monorepositories. It is unfortunate that this functionality is not available by default in npm in any way.
    - spankalee 3y ago
      npm workspaces plus Wireit works far better than Lerna, in my experience. https://github.com/google/wireit https://github.com/google/wireit Wireit's ability to specify actual script dependencies, do caching (and on Github actions), and its long-running service script support make it much more useful and comprehensive than Lerna. I agree that this should be built into npm. There's an RRFC for it here: https://github.com/npm/rfcs/issues/706 https://github.com/npm/rfcs/issues/706
- koromak 3y ago
  I did the same, switched back to npm in 2018/19 as I saw the majority of packages I was using doing the same. But in 2022-2023, I feel like I'm starting to see a lot of yarn again. Maybe just anecdotal, or maybe something changed I'm not aware of.
ruffrey 3y ago
Same here. Npm seems to have fixed the lock file issues it had, which was the main reason. With caching, npm is fine. On large projects npm ci can take 2 minutes - we leverage node modules cache on the lock file hash, and it’s typically fast.
xjidjccudux 3y ago
[dead]
joduplessis 3y ago
Workspaces is where npm falls apart.
- Inviz 3y ago
  What are your problems with workspaces? For my use it works pretty well: * Deduplicates versions of packages across workspaces (desirable for some projects) * No-configuration linking between workspace modules * Doesnt force using a specific structure * Top level module can be used to specify shared versions
- steve_adams_86 3y ago
  Yeah, my major foray into Yarn was to create workspaces for a monorepo without adopting other larger libraries with significant buy-in. I was glad I did it, and my team was, but it was a super-hairy experience trying to get all of the tooling happy within workspaces. I'm sure it's all a lot nicer these days.
meiraleal 3y ago
Npm served well but recently I've being noticing that I don't need NPM at all. For the frontend ESM modules from urls works very well. For the backend, deno can be a good alternative if it means not needing to use npm anymore.
a13o 3y ago
I view yarn as collective leverage over npm's product roadmap. As long as the npm roadmap doesn't stray too far from what developers want, or ship those things too slowly, there should be no need to use yarn. But for that to work, yarn needs to remain a credible alternative, so that it's actually possible to overcome the switching cost.
MuffinFlavored 3y ago
Recently ran into a project that uses https://pnpm.io/ https://pnpm.io/ Add that to the mix... In a similar vein, https://github.com/lerna/lerna https://github.com/lerna/lerna I am not sure when to use `npm workspaces` instead of lerna now? It seems like the answer (for me at least) was "you don't need lerna anymore given recent (past 2 years) NPM updates"

gryn 3y ago

the reason to try yarn for me was berry pnp to avoid those pesky node_module folders but alas the experience has been bumpy on personal projects. for something that has promised more robustness, it has been anything but that. I still like the yarn cli more than the npm one, but I ended up just defaulting to npm.

lucideer 3y ago

> But why would I use yarn today? I think many many many people switched to Yarn 1.x wholesale and then switched back to NPM once it had undergone some improvements.

leptons 3y ago
That's me. But for some projects I've had to switch back to yarn, because npm no longer works to install node_modules, and I don't really care why. Yarn works on those projects, npm does not. If npm works for a project, I use that, but there are some where yarn works and npm simply errors and quits.
spankalee 3y ago
This is exactly what I did. I even participated in the Yarn project a bit before it was fully open, but as npm 6 and 7 brought major speed improvements, workspaces, and overrides, I don't see the need for an alternate package manager anymore. As a library maintainer using the same package manager that most of my users do is a pretty big help. I'll be very happy when npm's linked install strategy is stable so that there's less reason to use pnpm and we get dependency isolation in monorepos.
- bhouston 3y ago
  > I don't see the need for an alternate package manager anymore. I do see a strong need for lerna though. Lerna's ability to manage concurrency, topological sort-based builds and streaming builds is phenomenal and an absolute necessity in monorepositories. It is unfortunate that this functionality is not available by default in npm in any way.
  - spankalee 3y ago
    npm workspaces plus Wireit works far better than Lerna, in my experience. https://github.com/google/wireit https://github.com/google/wireit Wireit's ability to specify actual script dependencies, do caching (and on Github actions), and its long-running service script support make it much more useful and comprehensive than Lerna. I agree that this should be built into npm. There's an RRFC for it here: https://github.com/npm/rfcs/issues/706 https://github.com/npm/rfcs/issues/706
koromak 3y ago
I did the same, switched back to npm in 2018/19 as I saw the majority of packages I was using doing the same. But in 2022-2023, I feel like I'm starting to see a lot of yarn again. Maybe just anecdotal, or maybe something changed I'm not aware of.

ruffrey 3y ago

Same here. Npm seems to have fixed the lock file issues it had, which was the main reason. With caching, npm is fine. On large projects npm ci can take 2 minutes - we leverage node modules cache on the lock file hash, and it’s typically fast.

xjidjccudux 3y ago

[dead]

joduplessis 3y ago

Workspaces is where npm falls apart.

Inviz 3y ago
What are your problems with workspaces? For my use it works pretty well: * Deduplicates versions of packages across workspaces (desirable for some projects) * No-configuration linking between workspace modules * Doesnt force using a specific structure * Top level module can be used to specify shared versions
steve_adams_86 3y ago
Yeah, my major foray into Yarn was to create workspaces for a monorepo without adopting other larger libraries with significant buy-in. I was glad I did it, and my team was, but it was a super-hairy experience trying to get all of the tooling happy within workspaces. I'm sure it's all a lot nicer these days.

meiraleal 3y ago

Npm served well but recently I've being noticing that I don't need NPM at all. For the frontend ESM modules from urls works very well. For the backend, deno can be a good alternative if it means not needing to use npm anymore.

a13o 3y ago

I view yarn as collective leverage over npm's product roadmap. As long as the npm roadmap doesn't stray too far from what developers want, or ship those things too slowly, there should be no need to use yarn. But for that to work, yarn needs to remain a credible alternative, so that it's actually possible to overcome the switching cost.

MuffinFlavored 3y ago

Recently ran into a project that uses https://pnpm.io/ https://pnpm.io/ Add that to the mix... In a similar vein, https://github.com/lerna/lerna https://github.com/lerna/lerna I am not sure when to use `npm workspaces` instead of lerna now? It seems like the answer (for me at least) was "you don't need lerna anymore given recent (past 2 years) NPM updates"