Comment by partsch
1 month ago
I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.
1 month ago
I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.
Of course. Modern Yarn releases (4.x) are deterministic to a fault and you can rely on it to have a consistent behavior across your whole team. As for feature-wise I'd say it's a lot of small details that together add up once you grow used to them.
The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs improvements.
Disclaimer: I'm the Yarn lead maintainer.
It was a giant mistake to keep 'classic' (umnaintained, unpatched) yarn around. Switched to pnpm in part due to that reason.
It's not exactly unmaintained (we merged a couple of security patches in the past years), I agree that we should have do something about it.
We'll be correcting this situation starting from the 6.x release, which we expect somewhere in August.
Deterministic to a fault unless you mix Windows and Linux.
https://github.com/yarnpkg/berry/issues/6105
As mentioned in the issue you link the problem comes from third-party packages with non-deterministic build scripts in git dependencies, or files on disk being actually different (although I guess we could at least try to normalize crlf, but as you can guess it will break someone).
1 reply →
I worked on a project that used yarn from the early days all the way up to v3, it's slow as hell, but it works. They also have the supply chain protections.
Eventually we snapped and migrated to pnpm. Installs (both in CI and on local dev machines) are significantly faster. Turned out to be about a day's work to migrate with an LLM's help.
I don't doubt that 3.x probably has worst perfs (it's almost two years old now), but just to clarify we closely track performances and Yarn and pnpm and pretty much on similar level:
https://p.datadoghq.eu/sb/d2wdprp9uki7gfks-c562c42f4dfd0ade4...
[dead]
One distinguishing feature is their optional install strategy: running packages directly from compressed archives instead of unpacking them into node_modules.
https://yarnpkg.com/features/pnp
Very similar to using .jar's in Java instead of directory trees of .class files.
It's somewhat hacky though, and editor/tool support varies.
- since there are far fewer small files, it can be faster especially on Windows if you're forced to work on it for some reason
- the archives can be stored into the git repository (through git-lfs or friends), removing dependency on the internet and the package registry
Though I mostly use pnpm these days, yarn still has a feature that I frequently miss: the project-local cache[0]. Basically, every dependency archive fetched from a registry is stored in your repo in .yarn/cache, so unless you're adding/updating dependencies a `yarn install` will work fully offline.
I'm sure there are drawbacks to this method regarding repo size etc., but it just feels good knowing that my repo contains everything needed to install and run any version of my project.
[0]: https://yarnpkg.com/features/caching#offline-mirror
I should add: this is enabled by adding `enableGlobalCache: false` to .yarnrc.yml, though I think it was the default for a bit when Yarn 2 first released.
I don't know what NPM is doing, but yarn installs deps much faster than NPM
I feel like Bun is even faster than yarn, but I'm afraid to keep using Bun since they made AI rewrite it completely in another language
To the people downvoting my comment: Feel free to answer my question. I really don't know the answer.