yarn with zero-installs removes an awful lot of pain present in npm and pnpm. Its practically the whole point of yarn berry.
Firstly - with yarn pnp zero-installs, you don't have to run an `install` every time you switch branch, just in case a dep changed. So much dev time is wasted due to this.
Secondly - "it worked on my machine" is eliminated. CI and deploy use the exact same files - this is particularly important for deeply nested range satisfied dependencies.
Thirdly - packages committed to the repo allows for meaningful retrospectives and automated security reviews. When working in ops, packages changing is hell.
All of this is facilitated by the zip files that the comment you replied to was discussing, that you tangented away from.
The graph you have linked is fundamentally odd. Firstly - there is no good explanation of what it is actually showing. I've had claude spin on it and it reckons its npm download counts. This leads to it being a completely flawed graph! Yarn berry is typically installed either via corepack or bootstrapped via package.json and the system yarn binary. Yarn even saves itself into your repo. pnpm is never (I believe) bundled with the system node, wheras yarn and npm typically are.
The way to do this today is to do it outside of node. Using an overlay fs with the overlay being a ramfs. You can even chroot into it if you can't scope the paths you need to be just downstream from some directory. Or, just use docker.
yes and no. Waiting 40mins for every test run is pure pain, platform specific ramfs type mounting is quite scriptable. Yes some devs might need to install a dependency, but its not a complex script.
I had to laugh, because the post you're replying to STRONGLY reminds me of this story, https://news.ycombinator.com/item?id=31778490 , in which some people on the GNOME project objected to thumbnails in the file-open dialog box because it might be a "Security issue" (even though thumbnails were available in the normal file browser, something those commenters probably should have known about, but didn't, but they just had to chime in anyway).
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.
This rule is very important. Like many of the other rules, it is open to interpretation, but it is a line in the sand that defines allowable behaviour and disallowable behaviour.
This rule will have an effect on the behaviour of the 'good players', and make the 'bad players' a lot easier to spot. Moderation needs this. I see this as stopping a race-to-the-bottom on value extraction from HN as a platform.
When I was a kid, the first "special" Lego kit I remember was the Star Wars sets in 1983 (and especially that everybody wanted a Millenium Falcon but I didn't know anybody who had parents that could afford one!)
Apart from those Star Wars kits, everything I had were generic blocks and strips (not sure what they're called, the ones that are 1/3 the height of a block) and some different designs of people. The closest I had to previous special sets was a town thing that my brother and sister had before me (they were 10 years older), which was a bunch of large floor tiles with roads and grassy areas with studs, some flowers pieces (single stud) and a handful of special buildings. But they were designed to be relatively generic, and the fun was using those building blocks to make a new city each time, not trying to recreate exactly someone's model. Apart from the flowers and the men, basically everything was a standard part, except perhaps a different colour.
When I was a teenager, the trend had become sets with lots of specialised parts for one specific model, such that they didn't really make sense as generic pieces. I enjoyed the technics kits because the early ones were just generic building blocks (apart from the wheels and rack and pinion, but again they could be re-used in lots of subsequent designs), but more and more the kits in the shops were for specialised models with unique pieces that were never designed to fit aesthetically with anything other than the model they came with. I'm sure _some_ people built other things with them, but equally I'd bet than probably 90% of those kits were built exactly once following the instructions and then never disassembled again.
The elements that are 1/3 the height of a brick is a plate if it has studs, and a tile if it does not.
Lego did not have Star Wars sets until 1998. The original Lego Millenium Falcon set 4504 would have retailed for right around $100. Which was high, but just as high as the bigger Castle sets at the time.
They definitely had lunar/space themed sets in the '80s, but they were generic (at least the ones I had). I don't recall when the Star Wars sets came out, they might have been one of the first cross-promotional tie-ins that Lego did?
Star Wars sets started coming out in 1998. They weren't the first licensed sets, but the first fictional license.
Prior to Star Wars, they had Shell, Exxon, and Esso branded sets. I think sometimes they licensed the Ferrari brand as well.
And yes, Lego has had a Space theme since the late 70s. But it was a general "Space" theme. They would later make Space Police, Blacktron, Magnetron, etc.
But actual Star Wars was 1998. I have some of those sets. It was a big deal to get an actual lightsaber hilt and blade.
Very interesting. Googling shows some generic space themed things from the 80s like you say, but no Star Wars. I guess my old age is finally catching up on me and my memories have all blurred into one. I did find a Millennium Falcon from 1983, but it's definitely not Lego.
Having grown up playing with LEGOs, I can still distinctly remember the feeling of sore fingers pulling tiny pieces apart after a long session. It wasn't until a few years ago I learned there's an official brick separator tool [1]. Would've changed my life as a kid.
reply