6 ms·

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

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.

andrew_ 5y ago
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.
renke1 5y ago
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+.
- chrisweekly 5y ago
  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-only-way https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the...
null_deref 5y ago
Does pnpm supports the behavior of > yarn install --offline ? A quick and lazy google search didn't yield a result...
arcatek 5y ago
We maintain a set of automated benchmarks against Yarn 1/2+ (PnP and node_modules tracked separately), pnpm, and npm: https://yarnpkg.com/benchmarks 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!
- k__ 5y ago
  pnpm is still around, cool! I didn't look into it since Yarn was released.
- IshKebab 5y ago
  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?
zkldi 5y ago
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.
- pas 5y ago
  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.
  - arcatek 5y ago
    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.
  - zkldi 5y ago
    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.
    - pas 5y ago
      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()
- 5y ago
joppy 5y ago
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.
paulddraper 5y ago
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.
- TechBro8615 5y ago
  I found these really useful at first, but have come to depend more on TypeScript project references for this now.

andrew_ 5y ago

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.

renke1 5y ago

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+.

chrisweekly 5y ago
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-only-way https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the...

null_deref 5y ago

Does pnpm supports the behavior of > yarn install --offline ? A quick and lazy google search didn't yield a result...

arcatek 5y ago

We maintain a set of automated benchmarks against Yarn 1/2+ (PnP and node_modules tracked separately), pnpm, and npm: https://yarnpkg.com/benchmarks 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!

k__ 5y ago
pnpm is still around, cool! I didn't look into it since Yarn was released.
IshKebab 5y ago
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?

zkldi 5y ago

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.

pas 5y ago
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.
- arcatek 5y ago
  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.
- zkldi 5y ago
  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.
  - pas 5y ago
    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()
5y ago

joppy 5y ago

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.

paulddraper 5y ago

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.

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