3 ms·

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 mil

by 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()
brundolf 5y ago
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

by zkldi 5y ago

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()

brundolf 5y ago

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