Hacker News Reader

Comment by d357r0y3r | Hacker News Reader

Anecdotally, it seems like a lot of Yarn adoption is still suck on 1.22.x. Migrating to 2+ appears to be untenable for many teams.

I understand that Yarn 2 is essentially a new tool, as there are certain features you simply can't ship while still being compatible with npm, but this hasn't resonated with developers. The initial appeal of Yarn 1 was that you could pretty much drop it into your node project and get much faster install times. `pnpm`, from what I understand, is faster than yarn, while still having that seamless interop w/ npm.

View on HN

While I personally enjoy Yarn 2+ a lot and prefer it for private projects (I'll explain a bit about my setup at the end), for a long time both the docs and the implementation pretty much guaranteed that it would fail:

- many basic things were missing from the docs for a long time, or at least were easier to find in Github issues (e.g. "what should I gitignore")

- defaulting to PnP meant that, without configuration, things wouldn't properly work on many projects based on frameworks/toolkits/editors

- opinionated defaults made things harder than necessary (e.g. why does `yarn init` create a Git repository?)

You either had to accept/work around these issues, or configure everything to work as e.g. npm or yarn 1 did. I did the latter, and am still happy that I bought in - but I can very much understand anyone who didn't.

My preferred setup with Yarn 2+ projects is:

- use the node-modules linker (I tried pnp every couple of months and always ran into some issue, which I sometimes sent PRs for, but there was always something not working)

- gitignore as described for zero-installs[0] (even though I don't use pnp; this has the advantage that you'll have a ZIP copy of every module cached, leading to very fast local/CI installs and resistance against registry issues)

- create .gitattributes file as described at the end of [0] to hide the binary files from diffs

- add the base SDK[1] for WebStorm support (this rarely worked well)

- add the TypeScript plugin

[0]: https://yarnpkg.com/getting-started/qa#which-files-should-be... [1]: https://yarnpkg.com/getting-started/editor-sdks

I cannot express how painful yarn pnp has been for us. We've been stuck on a relatively pretty old version of Typescript (4.8) because upgrading it with yarn is so difficult. You have to contend with Yarn patching Typescript, and requiring obscure IDE integrations so it all just works. We still can't update, because we can't get Typescript + Yarn PnP + VS Code on macOS to work together. It has been such a massive time sink for us.

I see no reason for anyone to use Yarn. Either use vanilla npm, or use pnpm which doesnt require a mountain of hacks to work.

We've been running TS + PnP + VSCode on MacOS throughout the entire lifetime of Yarn, through versions 1 - 4.

The plugins system has been extremely valuable to us, and the hoisting / peer dependency behavior has been consistently correct, where other package managers have caused bugs.

Yarn 2 (and 3) has been great for me, but I disabled PnP from the beginning, and only used the node-modules linker.

On top of the really different API, you always get v1 when you install (which I never understood). You need to upgrade manually everywhere with a command line. If I had to bet: most user didn't even bother upgrading because they are not aware of this behavior.

> you always get v1 when you install (which I never understood)

Yeah, they really wanted you to install yarn's source to your repo, which is why they don't let you `npm install` yarn v2 (or higher). That's maybe great for monorepos, but personally I find it ugly.

Thankfully now you can use `corepack`, which is shipped with npm. This way you can specify a version of yarn in packages.json, in the `packageManager` field. That is, without committing yarn's source to your repo.

I am learning this just now from this comment, so I think you are right.

Same here. I haven't done frontend in a few years now but I was shocked when the top comment was saying most people don't even use Yarn 2. I had no idea Yarn was past 1.x.

I like that Yarn 4 is installed into the project directory.

This way you always have the right version when cloning a random Yarn repo.

Always having the right version is nice. However, you can get similar benefits with a shorter bootstrap script. Personally I prefer this because there's less third party code duplicated directly to your own repo.

Yeah I followed the same path. I originally switched from npm to Yarn 1 for the speedup, but then Yarn 2 broke enough things that I never managed to upgrade.

pnpm is (at least) as fast as Yarn 1, and they managed to do it with a much better compatibility story (in my experience)

100% my experience too. I still find myself using yarn 1 for some new projects which do not support pnpm (strapi for example).

I remember upgrading yarn to yarn 2 and instantly regretting it then reverting.

I’m not stuck on Yarn 1, I’ve chosen to keep using it because it’s the best tool for my usage. I tried Yarn 2 and found it unsuitable, because:

- it patches packages to work with its PnP system

- even if you opt out of PnP

- in ways that are opaque for me as a user

- and in ways that break usage, eg it broke a beta version of TypeScript because the patch it wanted to apply wasn’t available for the beta

I’m sure the PnP feature is brilliant, but I don’t want to use it and I don’t want its behavior to be applied when I don’t use it. So Yarn 2+ is not an option for me. And since Yarn 1 is still supported, and meets my needs well, I continue to use it by choice.

fwiw the change specifically in this release (removing a lot of plugins) will make that adoption path a lot smoother.

Weirdly, going from v1 to v4 is a lot easier now than v1 to v2 or v1 to v3.

That being said... It's too little too late. I use `pnpm` now and maybe I'll use `bun` after total Node compatability.

Oh so that's why upgrading from yarn 1 to yarn 4 was so easy. It's using the "normal" install strategy into node_modules though.

Fully supporting the anecdata, different projects at my current company use all of the package managers — npm, yarn 1.x, pnpm, bun — except for yarn 2+

In personal projects I heavily gravitate towards bun as a package manager now, it's npm drop-in replacement but faster (and typing `bun run` is just so cute compared to `npm run`).

I'd love to use Bun for my projects, but it's not integrated into Corepack yet (and therefore you cannot pin the bun version w/ checksum in package.json)

https://github.com/nodejs/corepack/issues/295

yes bun as a package manager is great. I wouldn't advise anyone to run a production app with its runtime though. "drop-in replacement" for node was a lie with how many bugs and how much unimplemented stuff there is

I've been chatting with Jarred and it's obvious they care and want to make it better. But yes, the "1.0" release and claims like this hurt the sentiment for Bun. Hope it gets better, it's a seriously impressive (but monumental) undertaking.

totally agree. I'm rooting for them

Neither Yarn 1 nor pnpm have seamless interop with npm, but pnpm is more clear about this and you get the benefit of it's linked install strategy (which npm is adding, btw).

People really should get off of Yarn 1. It's not maintained, has a poor package locking system, and bugs will simply never be fixed.

I feel a bit scammed by yarn because I started using yarn when it came out and developed a muscle memory and appreciation for its CLI, and they just completely left the Yarn 1 users hanging while they have been messing around with the Yarn 2+ experiment. I don’t want to install Yarn 2 because it’s a weird hack, I just want them to go back to focusing on Yarn 1 goddammit.

Yarn v2 had support for just plain node modules, no PNP stuff but very few no about it even though it’s easy to setup and so much better than v1.

I stayed away from yarn@2+ for years, but finally switched to 3.2.1 when I started working on a monorepo with nested workspaces.

I've actually been really happy with 3.2.1. It and wireit together make it super easy to work on a project that spans various libraries/repos. PnP was a compatibility nightmare, but node-modules mode works.

It also has support for a pnpm-style linker which performs better than node-modules but is much less likely to break libraries.

Using the yarn pnpm linker seems like the worst of all options. It's clear it's not where the yarn team's focus is, not many people use it (relatively) so you're more likely to run into an undiscovered problem, and then it's still significantly slower than actual pnpm.

Switched over to yarn a while back. I’ve been developing some front-ends without even knowing yarn 2 was out there… The other day I started a new Next.js project and reached for yarn only to realize that it had jumped two versions (three now, apparently) I had to learn a bunch of new shit. I was like, nah, back to npm for me.

For comparison, not long ago I switched from pipenv to poetry and that was pretty much drop-in, with nevertheless markedly incremental improvements.

I love UI development. If only I could get to building the actual thing…

second this, I have aliased pnpm to my npm for two years, worked well and very speedy, saved lots of space too. I wonder how npm will borrow the new ideas from pnpm and yarn, fast.

In the last few places I worked we dropped Yarn for pnpm. Did the job and now dependabot can understand it too, on github.

Corepack is a nice addition to Node to make it easy to install a package manager but it's also an unwelcome layer of abstraction (why isn't there just one?).

What issues did you have with Dependabot and Yarn? We use it and it checks & updates lock files for both v1 and v2 Yarns

Dependabot only started supporting Yarn 2 and 3 in October of last year. Which at that point was over 2.5 years after the release of Yarn 2 itself.

I had just about convinced my team to use 1.X when the 2.0 design finalized. I give up.

As an occasional Yarn user, this is how I learned there is even versions beyond 1.22.

Reply on news.ycombinator.com