Live data from Hacker News

pnpm: Fast, disk space efficient package manager for JavaScript

pnpm.io

131–140 of 173 posts

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

#131

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

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.

I'm just now finding that webpack is mostly a foreign concept in backend nodejs tech, but it's mind boggling to me that the norm was to ship code with the node_modules folder instead of bundling and minifying. Seriously, why? It's so wasteful... :'(

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

#132

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

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.

If you want typescript on the BE then you at least need a build step.

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

#133
We switched our monorepo from yarn classic to pnpm and the install speeds have been night and day. Sometimes it feels like I ran the wrong command because its so fast.

pnpm also helped us solve issues with packages in our monorepo importing dependencies declared in other packages because of node_modules hoisting behaviour with yarn. With yarn, all of your packages' direct and indirect dependencies can be resolved from any package in your monorepo. This makes it hard to isolate packages from each other. For example, this was causing issues when we wanted to generate docker images for some of our packages since we only wanted to copy specific directories into the image rather than the entire monorepo to avoid having to bring the entire monorepo to the image. pnpm also allows us to use features like git sparse-checkout because we can be confident there are no implicit dependencies between packages.

pnpm makes this possible by only exposing in the node_modules direct dependencies. In monorepos that don't use pnpm, you can remove a dependency and your monorepo can break in unexpected places because other packages in the repo implicitly depend on this dependency. This is more common than you think because people tend to rely on IDE auto-completion when writing imports and IDEs just tend to read node_modules instead of package.json so its very easy to take on an implicit dependency when all directs/indirects are hoisted into a root node_modules.

Yarn supposedly fixes this issue in their newer releases with Plug n Play but from from what I understand it basically monkey patches Node's require statements with its own behaviour. This just didn't feel good to me from a tooling compatibility perspective which is why I went with pnpm and I'm glad I did. I'm honestly puzzled at Yarn's popularity and why pnpm isn't as popular as it should be.

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

#134

Earlier quoted context omitted.

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.

I'm just now finding that webpack is mostly a foreign concept in backend nodejs tech, but it's mind boggling to me that the norm was to ship code with the node_modules folder instead of bundling and minifying. Seriously, why? It's so wasteful... :'(

I just bundle everything except binary dependencies. Faster deployments

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

#135
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 went back to composer for a bit recently (PHP), and I was baffled when my install command did nothing other than install exactly the packages I’d specified. When I ran update, it didn’t modify any of my files, but went to the latest version matching the restrictions I’d specified in composer.json.

Such a breath of fresh air…

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

#136
post #104

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.

You don’t download the modules when your function starts. You include 500mb of dependencies in your 50kb lambda function.

The difference in boot time between 50kb and 500mb is quite significant.

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

#137

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

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.

If backend services are written in TS (instead of JS) then you'll need to compile to run it. Be that TSC or webpack with ts-loader, you'll need something to perform that step. I don't think anyone is running ts-node outside of local dev environments.

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

#138
post #135
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 went back to composer for a bit recently (PHP), and I was baffled when my install command did nothing other than install exactly the packages I’d specified. When I ran update, it didn’t modify any of my files, but went to the latest version matching the restrictions I’d specified in composer.json. Such a breath of fresh air…

very much the opposite of my experience. i'd gladly have 30 copies of left-pad living in my project rent free if it meant i never had to see "Your requirements could not be resolved to an installable set of packages" ever again.

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

#139
post #127
post #48

Earlier quoted context omitted.

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.

This amazes me as well. At work we have a simple website which has 1 GB of node_modules and the actual source code is well under a megabyte.

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

#140

As a person who uses npm just for some hobby coding projects, it's quite frustrating that there are new partly incompatible package managers for the javascript ecosystem: npm, pnpm, yarn, yarn 2. Some packages need one, some another, so I tried to switch to yarn (or yarn 2) for a package that I wanted to try out, but then other packages stopped working. If there are clearly better algorithms, why not refactor npm and…

Because npm maintainers do not, and apparently have never known, how a good package manager is supposed to work.

I have zero trust in NPM.

Post reply on HN