6 ms·

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

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.

ForkMeOnTinder 3y ago
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)
- makingstuffs 3y ago
  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.
animuchan 3y ago
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`).
- hardcopy 3y ago
  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 https://github.com/nodejs/corepack/issues/295
- willsmith72 3y ago
  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
  - dimgl 3y ago
    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.
    - willsmith72 3y ago
      totally agree. I'm rooting for them
synergy20 3y ago
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.
kylemh 3y ago
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.
- Narretz 3y ago
  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.
spankalee 3y ago
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.
- zarzavat 3y ago
  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.
benced 3y ago
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.
- doodlesdev 3y ago
  It also has support for a pnpm-style linker which performs better than node-modules but is much less likely to break libraries.
  - madeofpalk 3y ago
    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.
- bsimpson 3y ago
  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.
Timon3 3y ago
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-gitignored https://yarnpkg.com/getting-started/qa#which-files-should-be... [1]: https://yarnpkg.com/getting-started/editor-sdks https://yarnpkg.com/getting-started/editor-sdks
eyelidlessness 3y ago
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.
h1fra 3y ago
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.
- evtothedev 3y ago
  I am learning this just now from this comment, so I think you are right.
  - sli 3y ago
    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.
- k__ 3y ago
  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.
  - orra 3y ago
    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.
- orra 3y ago
  > 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.
ljm 3y ago
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?).
- morbicer 3y ago
  What issues did you have with Dependabot and Yarn? We use it and it checks & updates lock files for both v1 and v2 Yarns
  - scrose 3y ago
    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.
starlevel003 3y ago
As an occasional Yarn user, this is how I learned there is even versions beyond 1.22.
hinkley 3y ago
I had just about convinced my team to use 1.X when the 2.0 design finalized. I give up.
madeofpalk 3y ago
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.
- chatmasta 3y ago
  Yarn 2 (and 3) has been great for me, but I disabled PnP from the beginning, and only used the node-modules linker.
- killcoder 3y ago
  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.
aerhardt 3y ago
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…

ForkMeOnTinder 3y ago

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)

makingstuffs 3y ago
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.

animuchan 3y ago

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

hardcopy 3y ago
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 https://github.com/nodejs/corepack/issues/295
willsmith72 3y ago
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
- dimgl 3y ago
  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.
  - willsmith72 3y ago
    totally agree. I'm rooting for them

synergy20 3y ago

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.

kylemh 3y ago

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.

Narretz 3y ago
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.

spankalee 3y ago

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.

zarzavat 3y ago
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.

benced 3y ago

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.

doodlesdev 3y ago
It also has support for a pnpm-style linker which performs better than node-modules but is much less likely to break libraries.
- madeofpalk 3y ago
  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.
bsimpson 3y ago
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.

Timon3 3y ago

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-gitignored https://yarnpkg.com/getting-started/qa#which-files-should-be... [1]: https://yarnpkg.com/getting-started/editor-sdks https://yarnpkg.com/getting-started/editor-sdks

eyelidlessness 3y ago

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.

h1fra 3y ago

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.

evtothedev 3y ago
I am learning this just now from this comment, so I think you are right.
- sli 3y ago
  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.
k__ 3y ago
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.
- orra 3y ago
  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.
orra 3y ago
> 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.

ljm 3y ago

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

morbicer 3y ago
What issues did you have with Dependabot and Yarn? We use it and it checks & updates lock files for both v1 and v2 Yarns
- scrose 3y ago
  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.

starlevel003 3y ago

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

hinkley 3y ago

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

madeofpalk 3y ago

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.

chatmasta 3y ago
Yarn 2 (and 3) has been great for me, but I disabled PnP from the beginning, and only used the node-modules linker.
killcoder 3y ago
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.

aerhardt 3y ago

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…