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

101–110 of 173 posts

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

#101

Post by hirako2000 »

hbn wrote: post #32
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?

I'm sure Putin is reeling that he can't use an obscure package manager for his web projects

the idea is to anger the citizens so that they then turn their anger against Putin. it doesn't matter that Putin is not directly impacted.

I fundamentally disagree with the blockade. this moves makes this project incompatible with open source licensing.

if anyone is interested in this sub thread, it diverge from the discussion around the tool itself, but note that all the project standing for Ukraine in this manner are: - breaking one of the fundamental principle of open source - pretty risky to use. what if your locality also becomes block-listed. - demonstrates a poor judgment from their authors, who more often than not are reluctant to debate/reconsider their position.

Reactions to extreme circumstances can understandably be emotional, it doesn't imply that logical criticisms are necessarily insensitive.

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

#102

Post by hirako2000 »

dane-pgp wrote: post #87
triyambakam wrote: post #36

Earlier quoted context omitted.

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

People in Russia have access to millions of independent sources.

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

#103

Post by deckard1 »

lhorie wrote: post #85
fiddlerwoaroof wrote: post #83

Earlier quoted context omitted.

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…

Incompatible libs, you say? Try this one on: once upon a time a handful of years ago a package-lock.json I worked on drifted so far from package.json that you could not remove package-lock.json and rebuild purely from package.json. The versions specified in the package.json were incompatible with each other, but the package-lock.json had somehow locked itself to a certain permutation of versions that it somehow just worked.

I always shudder to think that different versions of packages live in node_modules and one library produces an object that somehow makes it to the other version of the library and... I'd rather not think of all these implications or I would go crazy.

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

#104

Post by 14u2c »

draaglom wrote: post #92
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…

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.

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

#105

Post by mmgutz »

hu3 wrote: post #6

Is there any gotcha if I switch from npm to pnpm? And can I use pnpm when working in a team where other devs use npm?

I ran into glitches around the pnpm script that wrap binaries. I had to change VS Code launch settings to use node directly to invoke the package bin.

Some create scripts invoked via `pnpx create...` exit the terminal without showing prompts. No issues running those scripts when using npm or yarn. IIRC, that was happening on Windows + Windows Terminal.

The name is too close to npm. I'll inadvertently type `npm` and that starts downloading all dependencies again. Of course I press `Ctrl+C` which has led to corruption of the node_modules folder on a few occasions.

I would not recommend mixing pnpm and npm. pnpm uses its own lock file. There's no guarantee your app/library will be using the exact package versions everyone else is using. That leads to it-works-on-my-machine kind of bugs.

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

#106

Post by chain-- »

jrochkind1 wrote: post #78
eyelidlessness wrote: post #27

Earlier quoted context omitted.

The point of peer dependencies is to allow users more flexibility in choosing the specific version of the dependency. It’s not intended to specify any kind of conflict between the packages, it’s effectively BYO sub-dependency.

regular traditional dependencies can already be specified as a range, yes? Any range the specifier wants (and can legitimately work with), yes? What is it about peer dependencies that give the host more flexibility in choosing the specific version? Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.

I could be wrong but I think it is used to alert you when you have incompatible dependencies.

For example if you have a dependency with a peerDependency `something: 2.x.x` and you currently have `something: 1.0.0` installed as a direct dependency, it will fail rather than allowing multiple versions to be run.

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

#107

Post by eyelidlessness »

jrochkind1 wrote: post #78
eyelidlessness wrote: post #27

Earlier quoted context omitted.

The point of peer dependencies is to allow users more flexibility in choosing the specific version of the dependency. It’s not intended to specify any kind of conflict between the packages, it’s effectively BYO sub-dependency.

regular traditional dependencies can already be specified as a range, yes? Any range the specifier wants (and can legitimately work with), yes? What is it about peer dependencies that give the host more flexibility in choosing the specific version? Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.

It allows packages to specify a wider version range for downstream users than a pinned version used in `devDependencies`. This is a common pattern if (say) your tests depend on certain less stable APIs but your published package only uses a smaller more stable subset. It’s especially useful if you want to support older semver-major versions, or even newer ones if you’re confident that the APIs you use will remain stable.

The example used in this post[1] on the Node blog is plugin systems, which is a very common expression of this pattern.

> Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.

I appreciate the clarification but it was clear to me the question was sincere FWIW! And yeah, a lot of this was hard for me to get a solid grasp on for quite a while. I think this tends to show up more in the JS ecosystem because semver was so eagerly adopted there, but I suspect it’s of similar benefit where semver is used and dev/prod dependencies is a proscribed distinction generally.

1: https://nodejs.org/es/blog/npm/peer-dependencies/

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

#108

Post by epolanski »

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…

Because symlinks solve all the pronlems of nesting and duplication while providing none that I can think of.

I've been using pnpm and rush in my projecrs, and going back to npm at my employer's every day is such a chore.

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

#109

Post by ricardobeat »

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…

As the post you shared yourself explains, peer dependencies were meant for plugins/extensions. It would make no sense for you to depend on “foobar” directly without having babel as a dependency already.

If foobar can be used standalone, then babel is a standard dependency, not a peer dept.

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

#110

Post by epolanski »

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?
Post reply on HN