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

121–130 of 173 posts

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

#121

Post by aabbcc1241 »

girvo wrote: post #115
xiphias2 wrote: post #76

Earlier quoted context omitted.

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.

Material UI (MUI for react) not just impact the DX, it also bloats the runtime impacting the UX

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

#122

Post by throwaway0x7E6 »

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…

No post body was provided.

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

#123

Post by mwid »

forty wrote: post #41

If you have a pnpm monorepo, you need to know about https://pnpm.io/filtering#--filter-since which allows to run your test/lint/etc on only the packages that have been impacted by changes from master.

I didn't know about this, thanks for posting! We have been using a custom Bash script to retrieve the list of sub-project directories that had been changed since the last commit by recursively scanning its sub-paths and running Git commands to find the last update on each, but this looks much, much better.

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

#124

Post by pragmatic »

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

Is this a thing? A buddy started at a new place and he was noticing webpack bundling for the backend.

Makes sense when you think about it I guess. Only used bundlers for front end stuff.

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

#126

Post by jmondi »

pragmatic wrote: post #125

For us peasants stuck in angular land: https://github.com/pnpm/pnpm/issues/3410 Seems this might not work with angular (yet)?

As long as you are on Angular 13, and all of your dependencies are updated and use the Ivy view engine, you should be good to go. You'll get really weird, hard to debug issues if any of your dependencies are using the older view engine.

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

#127

Post by topaz0 »

zkochan wrote: post #48
rplnt wrote: post #46

Slightly unrelated, but it always amazes me how big the dependency tree in js world can get. Hundreds of megabytes for SPAs. I don't understand js development or how anyone can live with that, but since I do need to edit it here and there I stumbled upon this handy tool. https://github.com/voidcosmos/npkill

It is unrelated because you don't have this issue with pnpm. pnpm uses a central content-addressable store and each unique file is written only once on a disk. It doesn't matter in how many projects you install the same dependency.

I think GP was amazed by the sheer number of dependencies, not by the how many of them are duplicated. It also amazes me. People talking above about having 10s of GB of dependencies. Crazy to me.

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

#128

Post by eyelidlessness »

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…

PNPM’s primary feature, even if it gets lost in all the optimization, is make it work, make it right. With an emphasis on the former serving the latter as the goal. FS links are an implementation detail. The thing it gets right is resolving only the dependencies you specify, unless you very clearly say otherwise. The way it does so just also happens to be efficient. If it’s confusing any other tools, they’re doing something wrong too. Links aren’t some wild new concept.

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

#129

Post by brainbag »

aabbcc1241 wrote: post #119
ramesh31 wrote: post #91

Earlier quoted context omitted.

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)

There's an npm package "narn" that uses commands akin to yarn's but will automatically use whatever package manager the current folder(/parent) is using. I almost never type npm or yarn or pnpm, just narn everywhere. Really handy.

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

#130

Post by geoffmanning »

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…

100% agreed here. If your package manager confuses established tooling and libraries, it's garbage. I recently started working at a company that uses this, and, horrifyingly, uses a monorepo, and their serverless lambdas are all at least 70+mb. I can't even fix it by using the webpack plugin because pnpm breaks webpack. Also worth noting that 90% of the "problems" that yarn and pnpm try to address were addressed by later versions of npm. Node, being very much tied to npm, doesn't need more package managers, it needs consensus and collaboration to improve on that consensus, and without breaking libs.
Post reply on HN