Hacker News Reader

Comment by FractalHQ | Hacker News Reader

I used to use yarn all the time until I tried pnpm. The speed is amazing, and as a traveler I love that it works offline by default. I’d be curious to see some benchmarks between pnpm and yarn 3, because pnpm has been the fastest of the bunch for me. It also gets bonus points for pnpx, workspaces, and essentially being a drop-in replacement for npm.

View on HN

We maintain a set of automated benchmarks against Yarn 1/2+ (PnP and node_modules tracked separately), pnpm, and npm: https://yarnpkg.com/benchmarks

The fastest are usually either Yarn PnP or pnpm. Note however that regardless of the package managers it's quite clear that performances are reaching a plateau in the common cases. I personally believe a better thing to consider are feature set, stability, documentation, and general codebase health (since it impacts how fast features and bugfixes ship, and how dangerous upgrades may be). But those are quite a bit harder to measure, of course!

pnpm is still around, cool!

I didn't look into it since Yarn was released.

Good benchmarks! Looks like pnpn is still quite a bit faster in most cases though. It does look like performance has reached a plateau, but a different plateau for different tools so surely it still makes sense to decide based on performance?

I've had a wonderful time with PNPM ever since switching for a couple of projects - installs are near instant, and my hard drive is no longer stuffed with a million installs of the same package in different places.

I always thought it was weird that npm didnt use a central store on your hard drive for your packages and instead just duplicated them everywhere, and i always thought it was even weirder that yarn didn't change this behaviour, but maybe i'm missing something.

Yarn did change this, but then it was rolled back, because too many things depended on actual files being there.

So now a project has to explicitly opt-in to Yarn pnp.

That's not quite true, PnP has always been the default and we have no plans to change that. The only thing that changed is that when you migrate from v1, we automatically enable the node-modules linker.

The reason for that is that PnP tends to require recent versions of some of your dependencies, so migrating to it can be somewhat involved, and it's better experience to let you keep using the install strategy you're used to until you decide to change it yourself.

New projects, on the other hand, already use the latest versions from their dependencies, so it's a much better starting point for PnP.

Sorry for the long delay on replying to this - what packages depend on files being there? I've never had a single issue with pnpm's approach to package management, minus some poor support from github.

I have no idea, but that's the rationale in the Yarn docs.

Probably any package that ships assets (static files) and uses file I/O to read instead of require()

I think having a simple global cache is fine, but otherwise I much prefer NPM's approach where all dependencies are contained in the project directory over Python's where everything is tangled up in your global system environment

Please, if you're downvoting this, share why. The replies here are full of valid anecdotal evidence for every package manager being mentioned, and they're all valid. If you feel this is invalid or poor content to be sharing, please state why so conversation can be had.

I agree - PNPM supports workspaces, is incredibly fast, and is space-efficient (it more or less builds node_modules out of symlinks back to somewhere central on your local machine). It also structures the node_modules folder correctly unlike NPM and Yarn, making it very difficult to import a library that you haven’t explicitly declared a dependency on.

pnpm is really good. The workspace implementation is the only one that feels (mostly) intuitive and also comes with certain functionality usually associated with tools like Lerna. It also doesn't seem to break certain expectations that packages make in regard to node_modules and the like. While there a few things that could be improved, I think it's definitely worth a try and provides a good compromise between NPM and Yarn 2+.

AND it is the only one of the three with a well-thought-out approach to node_modules^1

1. https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the...

One of yarn's best features (still not implemented by npm, but give it a few years) is resolutions.

You can override any version of a package anywhere in the dependency tree. For example, to resolve a CVE in one of your zillion packages.

pnpm has "hooks" which can do that and more, though I still prefer yarn resolutions.

I found these really useful at first, but have come to depend more on TypeScript project references for this now.

Does pnpm supports the behavior of > yarn install --offline ?

A quick and lazy google search didn't yield a result...

Reply on news.ycombinator.com