Hacker News Reader

Hacker News

Comment by HatchedLake721 | Hacker News Reader

Full thread

HatchedLake721

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

View on HN

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

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.

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.

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

npm workspaces plus Wireit works far better than Lerna, in my experience.

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

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.

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.

Recently ran into a project that uses https://pnpm.io/

Add that to the mix...

In a similar vein,

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"

Workspaces is where npm falls apart.

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

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.

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.

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.

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.

Reply on news.ycombinator.com