Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

pnpm: Fast, disk space efficient package manager for JavaScript

pnpm.io

Post reply on HN
Print view View original

81–90 of 173 posts

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#81

Post by [deleted] »

specialist wrote: post #75
steven-xu wrote: post #40

Summarizing 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 i…

> 1 real copy of each dependency version... npm showed me that I lack creativity, for I could not imagine anything worse than maven. The ~/organization/project/release dir structure is the ONE detail maven got right. (This is the norm, the Obviously Correct Answer[tm], right?) And npm just did whatever. Duplicate copies of dependencies. Because reasons.

[deleted]

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#82

Post by jakubmazanec »

jrochkind1 wrote: post #77
jakubmazanec wrote: post #26

Earlier quoted context omitted.

I want to specify only those deps that I use directly. Imagine a `foobar` package, that has `babel` peer dependency because it does some transpiling or whatever. For me as a user of `foobar`, that Babel requirement could have been regular dependency instead of peer. I don't care, I don't use Babel. In another words - if a package manager has all the information necessary to install all dependencies, why should I add…

I am so confused about the purpose of a "peer dependency" in the first place then.

You can read here why the peer deps were introduced: https://nodejs.org/es/blog/npm/peer-dependencies/

Imagine this structure of packages:

  your-app/
  ├── dep-a/
  │   └── dep-c
  ├── dep-b  
  └── peer-dep
Very simplified: `dep-c` is dependency of `dep-a`, so it is installed in its node_modules, but `peer-dep` is peer dependency of `dep-a`, so it is in node_modules of `your-app`. `dep-b` could also define `peer-dep` as its peer dependency, so it is installed only once. When npm switched to flat node_modules structure, peer deps become somewhat redundant, but not quite. Pnpm, which uses symlinks to achieve proper node_modules structure while avoiding long filenames, combined with auto install of peer deps would be ideal package manager.

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#83

Post by fiddlerwoaroof »

specialist wrote: post #75
steven-xu wrote: post #40

Summarizing 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 i…

> 1 real copy of each dependency version... npm showed me that I lack creativity, for I could not imagine anything worse than maven. The ~/organization/project/release dir structure is the ONE detail maven got right. (This is the norm, the Obviously Correct Answer[tm], right?) And npm just did whatever. Duplicate copies of dependencies. Because reasons.

Node is doing the right thing: if two dependencies in maven have conflicting dependencies, maven just picks an arbitrary one as _the_ version, which results in running with an untested version of your dependency (the dependency is actually depending on a version the developers of that dependency didn’t specify). Because node allows the same dependency to be included multiple times, npm and friends can make sure that every dependency has the right version of its dependencies.

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#84

Post by tekkk »

I use pnpm only for monorepos for which I find it works quite well. Although at times there have been issues, mainly with symlinks getting messed up or linking to wrong dependencies. Well, mainly having multiple versions of same packages.

But all in all I'm glad they are moving the JS/TS ecosystem forward and other managers are catching up to their innovations and likewise. Great monorepo support I feel is a big necessity for a manager and well-working symlinking to prevent the insane node_modules sizes.

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#85

Post by lhorie »

fiddlerwoaroof wrote: post #83
specialist wrote: post #75

Earlier quoted context omitted.

> 1 real copy of each dependency version... npm showed me that I lack creativity, for I could not imagine anything worse than maven. The ~/organization/project/release dir structure is the ONE detail maven got right. (This is the norm, the Obviously Correct Answer[tm], right?) And npm just did whatever. Duplicate copies of dependencies. Because reasons.

Node is doing the right thing: if two dependencies in maven have conflicting dependencies, maven just picks an arbitrary one as _the_ version, which results in running with an untested version of your dependency (the dependency is actually depending on a version the developers of that dependency didn’t specify). Because node allows the same dependency to be included multiple times, npm and friends can make sure that…

> Node is doing the right thing

Node does a different thing. It can coalesce two different versions into one if the two things are within a certain semver range, but there's nothing that enforces whether things within a semver range are actually compatible. The most prominent example is Typescript, which famously does not follow semver. Another notable example of how NPM itself does things wrong is that it considers anything in the `^0.x` range as compatible, whereas semver distinctly says the 0.x range is "anything goes".

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#86

Post by physicsguy »

Chyzwar wrote: post #73

We migrated from pnpm to yarn3 with node_modules linker. pnpm focus on wrong things, speed, disk efficiently is less important than stable, reproducible, and developer experience of yarn3.

We did exactly the same, tried to uneject from CRA recently and just could not get it to work in PNPM, switched to Yarn and it just worked.

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#87

Post by dane-pgp »

triyambakam wrote: post #36
ttybird2 wrote: post #23

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

If Russians get used to using VPNs, they might have more opportunity to check independent news sources and see how the war is going, and what people in other countries think.

Ironically, blocking Russian IP addresses could be seen as a form of non-violent protest against Russian web censorship.

https://en.wikipedia.org/wiki/List_of_websites_blocked_in_Ru...

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#88

Post by zkochan »

jrochkind1 wrote: post #79
zkochan wrote: post #51

Earlier quoted context omitted.

That was the deal a few weeks ago. After the atrocities that their army has committed in my country, I do not think I will ever unblock traffic from Russian Federation.

If that's how it works, there's a lot of people on the planet who have good reason to block traffic from the USA. Fortunately for me as a developer in the USA, I guess most of them, in the Global south, aren't developers, or know they can't be successful as developers blocking traffic from the USA, no matter how many atrocities the US military or intelligence have committed in their countries. :(. I guess if they wan…

In the USA there are different people. Good and bad. There are states that are very conservative and there is California. There are some basic values that everyone agrees upon. I think nobody can claim that everyone is bad or good in the US. Same goes for any other democratic society. Same goes for Ukraine. There are a lot of people that I don't like in Ukraine.

In Russia there are some good people but they are in extreme minority. Extreme. Even the liberals in Russia are supporting the annexation of Crimea. Maybe the dictatorship is the reason, maybe the propaganda. I don't know and I don't care. This is how it is and I do what I can to exclude them from my life.

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#89

Post by CraigJPerry »

fiddlerwoaroof wrote: post #83
specialist wrote: post #75

Earlier quoted context omitted.

> 1 real copy of each dependency version... npm showed me that I lack creativity, for I could not imagine anything worse than maven. The ~/organization/project/release dir structure is the ONE detail maven got right. (This is the norm, the Obviously Correct Answer[tm], right?) And npm just did whatever. Duplicate copies of dependencies. Because reasons.

Node is doing the right thing: if two dependencies in maven have conflicting dependencies, maven just picks an arbitrary one as _the_ version, which results in running with an untested version of your dependency (the dependency is actually depending on a version the developers of that dependency didn’t specify). Because node allows the same dependency to be included multiple times, npm and friends can make sure that…

>> maven just picks an arbitrary one as _the_ version

No that’s never been the case. If you have conflicting versions of a dependency in your dependency graph, maven chooses the “nearest neighbour” version - it selects the version specified least far away from your project in the transitive dependencies graph.

Pinning a particular choice is easy too - you just declare the dependency and specify the version you want instead of relying on transitive deps.

Re: pnpm: Fast, disk space efficient package manager for JavaScript

#90

Post by kall »

I'm pretty immune to most JS ecosystem churn, but on package managers I'm feeling it.

All I want is a package manager that is correct, causes very few day to day issues and is going to work the same way for many years. Yet everyone seems to be optimizing disk usage and speed without even getting the basics (make it work, make it right) fully covered.

I don't understand why people are optimizing for disk space at all tbh. Like, have you ever edited a video project, used docker, installed Xcode? I cannot imagine what you must be doing for all node_modules combined to take up more than maybe 100 GB on disk.

pnpm seems to be the lightest of the bunch, which is nice but why even mess with symlinks and confuse other tools? Just put all the files in there, nest them and duplicate them and everything. I'll happily live with my 10 GB node_modules folder that never breaks and sometimes gives me a nice coffee break.

Possibly I'm actually just salty that Metro doesn't support symlinks and would otherwise be on the pnpm love-train.

Post reply on HN