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

71–80 of 173 posts

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

#71

Post by leshenka »

afavour wrote: post #37
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?

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.

“error 1020” is not a very descriptive thing and I bet that a regular person would just think the site is broken

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

#72

Post by citrons »

lelandfe wrote: post #69
vosper wrote: post #58

Earlier quoted context omitted.

Generally I've found sticking with npm to be best. It's not the super-slow thing that it was before, and I can't remember the last time a package didn't install because it wasn't compatible with npm. I tried pnpm and it didn't just work, so I gave up. I would revisit it, but npm works. These days I don't really see a reason to use yarn (but would like to hear them).

Yarn's workspaces provide some cool benefits to monorepos which AFAIK npm hasn't matched. You can get there with Lerna + npm, though.

I have so far had very good npm workspace experience. Just define "workspaces" property in package.json and your off. https://docs.npmjs.com/cli/v8/using-npm/workspaces

Right now only pain-point with npm is that "npm link" can't be forced to install peer dependencies so I'm unable to easily test typesscript built libraries within other projects.

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

#74

Post by trulyme »

5e92cb50239222b wrote: post #67
trulyme wrote: post #65

Earlier quoted context omitted.

Given what a dumpster fire npm ecosystem is security wise, it's best to run the whole build chain in a container anyway, at least for frontend apps. This way you also don't care about the chosen package manager or node.js version - you can just set it as you wish in the Dockerfile. It does take more disk space though, but to me it's a nice compromise.

Containers don't provide much protection from malware, unless you're running it rootless under an unprivileged user (no sudo access, no ssh keys or anything else interesting in the home directory, etc; and even then it's limited because the attack surface is enormous).

I mean, of course? Especially, why would I put ssh keys and similar in the container?

This still doesn't mean that one can install just any package, but it does make it much more difficult for it to do much harm. Breaking out of a container is not as trivial as it once was. That said, it is not a perfect solution, so I'd be happy to hear of better ones. Any suggestions?

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

#75

Post by specialist »

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.

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

#76

Post by xiphias2 »

zkochan wrote: post #59
xiphias2 wrote: post #55

Earlier quoted context omitted.

So it should just be backported to npm to show that the authors are serious about backwards compatibility.

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.

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

#77

Post by jrochkind1 »

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…

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

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

#78

Post by jrochkind1 »

eyelidlessness wrote: post #27
Wronnay wrote: post #15

Earlier quoted context omitted.

Yeah - this peer dependency thing always makes issues, when I try to upgrade a big Ionic project... Peer dependencies added more problems than they solved in my eyes... Most peer dependencies warnings come because some maintainer forgot to update the package.json and not really because two packages don't work with each other...

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.

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

#79

Post by jrochkind1 »

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.

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 wanted to try, it's an interesting question if that would be some kind of effective action in changing US atrocious behavior. Probably not. :(

That said, this is basically a form of boycott. There does seem to have been some significant change of opinion around the value and ethics of the tool, from when the main example we had was the BDS movement called by Palestinian civil society against Israel. (Which by the way, does not in fact call for doing things like blocking all network access to those in Israel, what people are doing against Russia is way broader and less targetted than what the... more controversial(?) Palestinian-led BDS has done or called for against Israel. Which is interesting.)

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

#80

Post by gizzlon »

trulyme wrote: post #74
5e92cb50239222b wrote: post #67

Earlier quoted context omitted.

Containers don't provide much protection from malware, unless you're running it rootless under an unprivileged user (no sudo access, no ssh keys or anything else interesting in the home directory, etc; and even then it's limited because the attack surface is enormous).

I mean, of course? Especially, why would I put ssh keys and similar in the container? This still doesn't mean that one can install just any package, but it does make it much more difficult for it to do much harm. Breaking out of a container is not as trivial as it once was. That said, it is not a perfect solution, so I'd be happy to hear of better ones. Any suggestions?

gVisor, VMs
Post reply on HN