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.
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)
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.
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.
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)
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.
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)
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
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.
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.
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?).
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.
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.
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"
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.
Yarn made the same mistake going from 1 to 2 as Angular did. The newer version was so different. Both should have been named something else. At a certain point of incompatibility and divergence it is a different product, and the benefit you get from using a well known name is outweighed but the cost of confusion.
Yarn 2 brought a lot of great improvements but since it was named "Yarn" people were expecting it to behave somewhat like the first one.
Sometimes I wish for a SemVer iteration that does away with the major version, and requires a project to create a new library wholesale if they want to increment the major version. Every library would have minor and patch releases, but if they want to substantially change the API, they'll have to create a new library instead and ask people to move to it instead.
The problem with semver is what constitutes "substantially"; because it's been left to subjective interpretation, we end up with these weird situations. What may invoke a feeling of "This should have been a new library" is different for each team. Even a minor change with a deprecated method can invoke such a reaction depending on how a team has been using that library.
Yarn lost the plot when going to v2. It was very different from v1. Even attempting a migration was painful enough to write it off completely in the projects I was working on. I've yet to come across any new projects using Yarn since then. Now, I think it is too late. pnpm has more or less caught up and even surpassed any advantages Yarn had, with a much more pragmatic compatibility across multiple platforms.
Personally, I've moved on to pnpm (with npm as a fallback when I can't use pnpm).
a) pin your dependencies, set save-prefix='' in .npmrc, use a tool like pnpm outdated, Renovate, Dependabot, npm-check-updates to keep them updated. Doesn't need to be done or enforced in the package manager, Git Hooks and CI are sufficient.
b) use syncpack to ensure all your dependencies in different workspaces use the same versions. This doesn't need to be done in the package manager.
pnpm also has pnpm licenses to help keep compliance happy.
If someone wants to write a package manager in Rust for speed (pnpm is already moving in this direction, see https://github.com/pnpm/pn and https://github.com/pnpm/pacquet ), we'd take a look. Otherwise - not enough benefit to switching away.
I'm just trying to switch to pnpm and I'm a bit lost on how to dockerize packages in my workspace, something that I thought would be a common thing to do.
The example in their docs [1] seems to just be wrong
This of course will not work, since the node_modules folders of packages in a pnpm workspace just contain symlinks to the virtual store at the root of the monorepo, not the actual modules.
I don't see any good way to do what this example pretends to achieve (minimize docker image build size) since even when hoisting is forced, pnpm seems to only ever hoist node_modules in the root of the repo.
Sorry for this somewhat unrelated rant, I was just surprised at hitting such an obstacle immediately after trying to adopt pnpm after I heard so much praise for this tool.
Checkout Depot's example Dockerfile for node + pnpm: https://depot.dev/docs/languages/node-pnpm-dockerfile which is best-practices based even if you're not using Depot. They also explain each of the lines in the Dockerfile.
As someone struggling with Docker caching at work at the moment, I think your problem is less with pnpm and more with the difficulty of writing decent Dockerfiles.
pnpm is more than just pnpm install, there's an evolving ecosystem of tools. For a mainstream project looking for tools to depend on, either everything supports bun, or it might as well be nothing.
Same. I was using yarn 1 until a couple years ago. Now I just use npm. What are the downsides? I have no idea. If there are, they must be negligible because the apps work fine, customers are happy, and devs are able to keep building. We must not have any crazy dependencies because I don’t see much performance gains. At most we might link other packages as we develop.
I think if I really went searching for problems I might find something. I also just try to avoid JS these days unless it’s UI, and there I keep things very lean and straightforward.
The sole reason I haven't migrated to NPM to be honest is the lack of a replacement for "yarn run".
I use "yarn run" incredibly frequently, for things like "yarn run nodemon" and "yarn run tsc" or other executable packages that are local dependencies.
That's the thing with tools like this. Eventually whoever you one-upped just incorporates your features and now they have the edge again - your new features and their greater experience.
Yarn 2.0 was ambitious, but in hindsight, it probably would have been better to make regular node_modules the default rather than pushing PnP and zero installs (and alienating most users in the process).
I think Yarn Berry with node_modules linker is strictly better than Yarn 1.0, whereas PnP and zero installs involve tradeoffs that might not be right for everyone. There's a lot of great design decisions in Berry that gets muddled with all the PnP-related discussion. I will say Maël deserves a lot of credit for driving corepack, which makes version control of package management totally seamless. It's always been a total nightmare but now it's shockingly easy.
Yarn's versioning is really confusing. Is 4.0 compatible with 1.x? Is it a successor to Yarn 2 (with the different functionality)? What happened to 3? Haven't really kept up with this since 2 wouldn't work with any of my projects, not sure where to pick up again now...
I mean... Why would it be compatible with 1.x if 2 wasn't? There is an upgrade guide to upgrade from 1 to 2 and later. 3 has been out for a long time. Not sure how their versioning is confusing. It uses the major version number to signal (possibly) breaking changes.
IME most projects use semver to indicate possibly breaking changes that might require a manual fix or three, not a whole different project that requires 100% changes across the board and starting over from scratch. Even node itself doesn't just kill your projects with every major version.
Judging by the other comments in this thread, and the blog post saying that "zero-install is disabled by default", I had kinda hoped 4 would be a reboot of Yarn v1 with modern conveniences. This does not appear to be the case.
I'm still not sure whether it goes like "2.x -> 3.x -> 4.x are all in the same line, and upgrading from 2 to anything beyond that is easy" or if they are each as different from each other as 2 was from 1. That's the confusing part. (Like, did the 2.x line stabilize into 4.x, or are these just four separate projects altogether?)
I think it would've been a lot clearer if they just named Yarn 2+ something entirely different, like Moment did with Luxon
Readit News
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.
- 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 see no reason for anyone to use Yarn. Either use vanilla npm, or use pnpm which doesnt require a mountain of hacks to work.
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.
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.
This way you always have the right version when cloning a random Yarn repo.
pnpm is (at least) as fast as Yarn 1, and they managed to do it with a much better compatibility story (in my experience)
I remember upgrading yarn to yarn 2 and instantly regretting it then reverting.
- 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.
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.
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`).
https://github.com/nodejs/corepack/issues/295
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'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.
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…
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?).
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).
I think many many many people switched to Yarn 1.x wholesale and then switched back to NPM once it had undergone some improvements.
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.
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.
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.
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"
* 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
I still like the yarn cli more than the npm one, but I ended up just defaulting to npm.
Dead Comment
Yarn 2 brought a lot of great improvements but since it was named "Yarn" people were expecting it to behave somewhat like the first one.
https://www.youtube.com/watch?v=oyLBGkS5ICk
Personally, I've moved on to pnpm (with npm as a fallback when I can't use pnpm).
> Hardened Mode, constraints engine
a) pin your dependencies, set save-prefix='' in .npmrc, use a tool like pnpm outdated, Renovate, Dependabot, npm-check-updates to keep them updated. Doesn't need to be done or enforced in the package manager, Git Hooks and CI are sufficient. b) use syncpack to ensure all your dependencies in different workspaces use the same versions. This doesn't need to be done in the package manager.
pnpm also has pnpm licenses to help keep compliance happy.
If someone wants to write a package manager in Rust for speed (pnpm is already moving in this direction, see https://github.com/pnpm/pn and https://github.com/pnpm/pacquet ), we'd take a look. Otherwise - not enough benefit to switching away.
The example in their docs [1] seems to just be wrong
> FROM common AS app1
> COPY --from=prod-deps /app/packages/app1/node_modules/ /app/packages/app1/node_modules
> COPY --from=build /app/packages/app1/dist /app/packages/app1/dist
This of course will not work, since the node_modules folders of packages in a pnpm workspace just contain symlinks to the virtual store at the root of the monorepo, not the actual modules. I don't see any good way to do what this example pretends to achieve (minimize docker image build size) since even when hoisting is forced, pnpm seems to only ever hoist node_modules in the root of the repo.
Sorry for this somewhat unrelated rant, I was just surprised at hitting such an obstacle immediately after trying to adopt pnpm after I heard so much praise for this tool.
[1] https://pnpm.io/docker#example-2-build-multiple-docker-image...
As someone struggling with Docker caching at work at the moment, I think your problem is less with pnpm and more with the difficulty of writing decent Dockerfiles.
https://github.com/orogene/orogene
How about Zig?
Seriously, try Bun. It's stupid fast. Even if you don't use all its other features, just try "bun install".
pnpm is more than just pnpm install, there's an evolving ecosystem of tools. For a mainstream project looking for tools to depend on, either everything supports bun, or it might as well be nothing.
Why not?
I briefly tried Yarn 3 but it also did some weird things.
Here's to hoping that Yarn 4 "just works" the way Yarn 1 does.
I think if I really went searching for problems I might find something. I also just try to avoid JS these days unless it’s UI, and there I keep things very lean and straightforward.
I use "yarn run" incredibly frequently, for things like "yarn run nodemon" and "yarn run tsc" or other executable packages that are local dependencies.
I think Yarn Berry with node_modules linker is strictly better than Yarn 1.0, whereas PnP and zero installs involve tradeoffs that might not be right for everyone. There's a lot of great design decisions in Berry that gets muddled with all the PnP-related discussion. I will say Maël deserves a lot of credit for driving corepack, which makes version control of package management totally seamless. It's always been a total nightmare but now it's shockingly easy.
Judging by the other comments in this thread, and the blog post saying that "zero-install is disabled by default", I had kinda hoped 4 would be a reboot of Yarn v1 with modern conveniences. This does not appear to be the case.
I'm still not sure whether it goes like "2.x -> 3.x -> 4.x are all in the same line, and upgrading from 2 to anything beyond that is easy" or if they are each as different from each other as 2 was from 1. That's the confusing part. (Like, did the 2.x line stabilize into 4.x, or are these just four separate projects altogether?)
I think it would've been a lot clearer if they just named Yarn 2+ something entirely different, like Moment did with Luxon