This is because yarn patches fs in order to introduce virtual file path resolution of modules in the yarn cache (which are zips), which is quite brittle and was broken by a seemingly unrelated change in 25.7.
The discussion in issue 62012 is notable - it was suggested yarn just wait for vfs to land. This is interesting to me in two ways: firstly, the node team seems quite happy for non-trivial amounts of the ecosystem to just be broken, and suggests relying on what I'm assuming will be an experimental API when it does land; secondly, it implies a lot of confidence that this feature will land before LTS.
> firstly, the node team seems quite happy for non-trivial amounts of the ecosystem to just be broken
yarn/node relations specifically are... complicated. On display on corepack (yarn project which got bundled into official nodejs distribution) issue tracker.
> secondly, it implies a lot of confidence that this feature will land before LTS.
This confidence is somewhat concerning. Will it get reviewed at all or has the "trust the LLM" mandate arrived at Node too now.
This is quite spammy; you could mitigate it by explaining what you think the "needless suffering" is. Having been using npm, pnpm, and yarn for many years the only benefit I find with pnpm is a little bit of speed when using the cli, but not enough that I notice; I've outlined the major yarn benefit to me 'in a peer comment' (which I didn't realise was you when I answered) https://news.ycombinator.com/item?id=47415660
I expect yarn to have a real competitor sooner rather than later that will replace it; and I do wonder if it is this vfs module that will enable it.
For many years I was using yarn with 0 issue on massive monorepos, and every year I'd hear people hyping pnpm, I'd try and switch, run into multiple bugs often open issues in pnpm itself, yes even without their link strategy, then give up and wait. After about 3 years of this I gave up and never tried again.
This can't be overstated. The main benefit with yarn berry (v4+) is being able to commit the dependencies to the repo - I have yarn based tools that I wrote years ago that just work wheras I frequently find npm and python tools are broken due to version changes. However this benefit comes at a setup cost and a lot more on disk complexity - one off tools are just npm and done.
- https://github.com/yarnpkg/berry/issues/7065
- https://github.com/nodejs/node/issues/62012
This is because yarn patches fs in order to introduce virtual file path resolution of modules in the yarn cache (which are zips), which is quite brittle and was broken by a seemingly unrelated change in 25.7.
The discussion in issue 62012 is notable - it was suggested yarn just wait for vfs to land. This is interesting to me in two ways: firstly, the node team seems quite happy for non-trivial amounts of the ecosystem to just be broken, and suggests relying on what I'm assuming will be an experimental API when it does land; secondly, it implies a lot of confidence that this feature will land before LTS.