Does this use symlinks to a single copy of each dependency?
A single copy of each required version of each dependency.
So is that a yes? Or does it still pull a copy for each projects local node_modules?
pnpm: Fast, disk space efficient package manager for JavaScript
31–40 of 173 posts
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#32Please note that pnpm is currently blocking all traffic from Russia and Belarus https://twitter.com/pnpmjs/status/1498306992577957890
"We will unblock it when you stop the war and de-occupy all the Ukrainian territory." There's what, maybe a handful of people who can make that happen?
I'm sure Putin is reeling that he can't use an obscure package manager for his web projects
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#33Please note that pnpm is currently blocking all traffic from Russia and Belarus https://twitter.com/pnpmjs/status/1498306992577957890
Слава Україні!
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#34We recently started sponsoring pnpm[1] as well as adding zero-config support for deployments and caching. I think pnpm is an incredible tool. Excited to see it grow further. [1]: https://vercel.com/changelog/projects-using-pnpm-can-now-be-...
Thank you!
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#35pnpm is awesome except when it does not work - which happens very rarely but it is a nightmare to debug. For all the other times, it is way faster and lightweight than npm.
I was unable to use pnpm with a project that used Electron (~2 years ago), IIRC because some spawned process was incompatible with symlinks. It's the only time it caused me trouble though, it's indeed much faster than npm. I'd love to use it at work too.
In any cases where pnpm doesn't work, you may set the node-linker=hoisted option and it will work:
https://pnpm.io/npmrc#node-linker
With node-linker=hoisted, pnpm creates a traditional hoisted (aka flat) node_modules, without using symlinks.
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#36Please note that pnpm is currently blocking all traffic from Russia and Belarus https://twitter.com/pnpmjs/status/1498306992577957890
And then they suggest that Russian users use a VPN to get through. I don't understand this line of thinking at all.
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#37Please note that pnpm is currently blocking all traffic from Russia and Belarus https://twitter.com/pnpmjs/status/1498306992577957890
"We will unblock it when you stop the war and de-occupy all the Ukrainian territory." There's what, maybe a handful of people who can make that happen?
Russian TV is wall to wall coverage about their highly successful campaign to eradicate Ukrainian Nazis. An action like this might at least be a small hint to everyday Russians that things aren’t as they appear.
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#38Please note that pnpm is currently blocking all traffic from Russia and Belarus https://twitter.com/pnpmjs/status/1498306992577957890
[deleted]
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#39Re: pnpm: Fast, disk space efficient package manager for JavaScript
#40Summarizing the 3 major JS package management approaches:
* Classic node_modules: Dependencies of dependencies that can't be satisfied by a shared hoisted version are nested as true copies (OSes may apply copy-on-write semantics on top of this, but from FS perspective, these are real files). Uses standard Node.js node_modules resolution [1].
* pnpm: ~1 real copy of each dependency version, and packages use symlinks in node_modules to point to their deps. Also uses standard resolution. Requires some compatibility work for packages that wrongly refer to transitive dependencies or to peer dependencies.
* pnp[2]: 1 real copy of each dependency version, but it's a zip file with Node.js and related ecosystem packages patched to read from zips and traverse dependency edges using a sort of import map. In addition to the compatibility work required from pnpm, this further requires compatibility work around the zip "filesystem" indirection.
In our real-world codebase, where we've done a modest but not exhaustive amount of package deduplication, pnpm confers around a 30% disk utilization savings, and pnp around a 80% savings.
Interestingly, the innovations on top of classic node_modules are so compelling that the package managers that originally implemented pnpm and pnp (pnpm and Yarn, respectively) have implemented each others' linking strategies as optional configs [3][4]. If MacOS had better FUSE ergonomics, I'd be counting down the days for another linking strategy based on that too.
[1] - https://nodejs.org/api/modules.html#loading-from-node_module... [2] - https://yarnpkg.com/features/pnp [3] - https://github.com/pnpm/pnpm/issues/2902 [4] - https://github.com/yarnpkg/berry/pull/3338