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.
pnpm: Fast, disk space efficient package manager for JavaScript
131–140 of 173 posts
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#132Earlier 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.
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#133pnpm 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
#134Earlier 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... :'(
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#135I'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…
Such a breath of fresh air…
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#136Earlier 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.
The difference in boot time between 50kb and 500mb is quite significant.
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#137Earlier 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.
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#138I'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
#139Earlier 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.
Re: pnpm: Fast, disk space efficient package manager for JavaScript
#140As 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…
I have zero trust in NPM.