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

111–120 of 173 posts

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

#111

Post by djbusby »

14u2c wrote: post #104
draaglom wrote: post #92

Earlier quoted context omitted.

I'm not sure if this is the _main_ reason, but one thing that makes node_modules size more than an aesthetic concern is serverless. Booting a serverless function with 100s of mbs of modules takes an appreciable time - to the point where some folks webpack bundle their serverless code

Are people actually downloading dependencies on the fly like this? IMO a bundler is absolutely essential. What if npm is down? What if the version of a dependency has been deleted for some reason? These are surprises you absolutely do not want when a function is starting.

Or left-pad or that other one. JS ecosystem seems dangerous to no version pin, pack and maybe self-host the needed+known-good modules

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

#112

Post by epolanski »

jakubmazanec wrote: post #26
ricardobeat wrote: post #14

Earlier quoted context omitted.

Isn't that exactly how it's supposed to be? If you're installing a package that has peer dependencies, you should already depend on them. Otherwise they are not "peer dependencies" anymore, just a normal dependency with a version range. The whole peer dependencies story is another clusterfuck. Everyone simply ignored the invalid peer dependency warnings, and now npm itself will just install all of them in 'whatever w…

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…

That implies babel was a dependency not a peer one.

Peer dependencies are for extensions and for plugins to an existing stack, as material-ui has a peer of react or io-ts on fp-ts

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

#114

Post by epolanski »

zkochan wrote: post #88
jrochkind1 wrote: post #79

Earlier quoted context omitted.

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 ex…

There's different people in Russia too. No one is blocking US citizens because they dropped bombs killing 300 people shopping in markets or 200k civilians in Iraq or for the many abuses like Abu Grahib.

Actually america has been by far the biggest aggressor on the planrt in tge last decades, and it killed the most civilians outside Africa.

That's my problem with this massive anti russian hysteria in software.

You only appear careless, racist and naive. It's better to avoid politics in software and business, because if you don't you have to basically ban anyone.

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

#115

Post by girvo »

xiphias2 wrote: post #76
zkochan wrote: post #59

Earlier quoted context omitted.

Both pnpm and Yarn are independent projects maintained by the community. I personally think that these are better projects than npm CLI because they can make their own decisions. Not decisions dictated by business needs of a company. I was OK to merge pnpm into npm in the past. They have never suggested me this opportunity. Instead, they decided to re-implement pnpm's algorithm into npm and call it "isolated mode".

I see, I tried it now, it looks great. Most of my problems were created by the material UI libraries (I wanted to use them with SvelteKit), but I just got rid of it as those libraries were making development harder instead of helping. I still wish there would be a nice UI library for Svelte, but I guess that's the disadvantage of not going with the mainstream frontend toolkit.

> ...material UI libraries...making development harder instead of helping.

I'm glad I'm not the only one who has had that experience.

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

#116

Post by epolanski »

zkochan wrote: post #51
duxup wrote: post #29

Earlier quoted context omitted.

"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?

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.

> After the atrocities that their army has committed in my country, I do not think I will ever unblock traffic from Russian Federation.

Are you gonna ban Israeli for their apartheid, chinese for the uighurs concentration camps, myanmari for ethnic cleansings of Rohingya? What about americans and the 200k civilians killed in iraq in an illegal and unprovoked aggression?

See what's the point of doing lame politics like that? You end up declaring to the world that 800 villages burned and 50k civilians thrown in fire matter none to you because they aren't white.

I feel disgust at these double standards, at showing to the world that there are tier 1 and tier 2 victims.

Or do you just care a

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

#117

Post by girvo »

epolanski wrote: post #110
rauttis wrote: post #47

I recently migrated a fairly large monorepo (20+ packages) that used Lerna and npm to pnpm, and the improvement in developer experience was pretty massive. Dependency install times went down by a huge amount, and all the strange issues we had with lerna and npm sometimes erroring out, requiring us to remove all node_modules folders and re-install everything, are just gone. We even noticed that the size of some of our…

Why not use rush as well?

Probably because Lerna is already working for them. We're just using straight Yarn workspaces ourselves. Rush is great, but for our project it's overkill (lerna was as well).

Though we're using git submodules + yarn workspaces right now. The submodules will likely go away eventually.

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

#118

Post by tored »

sam_goody wrote: post #100

with its linking strategy, pnpm allows for multiple versions of the same package. I wish there was something like that in PHP's Composer, where I have repeatedly hit situations where different packages have a dependency that was pinned to a different version (such as one package using Guzzle 6 and another Guzzle 7), and therefore my composer.json was un-buildable. (I have less experience with NPM so I don't know if t…

Problem is that it can’t be done in PHP without on-the-fly rewriting of source files.

In JavaScript the caller decide how a module should be used by importing it to symbol, thus different versions of the same library can exist simultaneously.

In PHP it is the callee that decides how to be imported because of namespaces.

One and only one class with that exact name and namespace can exist at a given time, thus different versions of the same library can’t be loaded simultaneously.

That is why modules are far superior over namespaces.

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

#119

Post by aabbcc1241 »

ramesh31 wrote: post #91
kall wrote: post #90

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…

NPM just has too much institutional inertia to avoid. The moment you make the decision to use something else, you are simply trading one set of warts for another. I can't even tell you how many projects I have seen waste countless hours of dev time on Yarn/NPM discrepancies. If you are working on anything with more than two people, you really need to just use the standard tooling that everyone is familiar with and th…

I have custom bash scripts named npm and yarn, they invoke pnpm for installing and uninstalling packages, and fallback on other commands (e.g. audit).

This way work well with other tools (e.g. I can force create-react-app to install packages with pnpm)

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

#120

Post by aabbcc1241 »

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…

If your file system supports compression, (e.g. zfs and btrfs) then the actual disk usage of pnp and pnpm should be similar ?
Post reply on HN