Comment by kall | Hacker News Reader

Comment by kall | Hacker News Reader

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 tbh. Like, have you ever edited a video project, used docker, installed Xcode? I cannot imagine what you must be doing for all node_modules combined to take up more than maybe 100 GB on disk.

pnpm seems to be the lightest of the bunch, which is nice but why even mess with symlinks and confuse other tools? Just put all the files in there, nest them and duplicate them and everything. I'll happily live with my 10 GB node_modules folder that never breaks and sometimes gives me a nice coffee break.

Possibly I'm actually just salty that Metro doesn't support symlinks and would otherwise be on the pnpm love-train.

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 that the entire ecosystem is based around. Anything else is yak shaving.

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.

I added the script to PATH, so other tools that hard-coded to use yarn or npm (e.g. create-react-app) are hijacked to use pnpm when installing packages

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.

Until it breaks on a fresh install? Reproducibility is a must.

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.

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.

Or left-pad or that other one. JS ecosystem seems dangerous to no version pin, pack and maybe self-host the needed+known-good modules

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.

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

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

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.

You can use pnpm without symlinks by setting node-linker=hoisted

https://pnpm.io/npmrc#node-linker

That's great news! pnpm might be my answer after 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.

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.

yarn1 used to have a global package cache (enabled by default), but now it's disabled, because many packages don't work if they are symlinked.

Other than the biggest OS pretty much choking on the node_modules black hole whenever you do a global operation on it (try deleting a js project on Windows)

rimraf is your friend

Some years back, when npm itself didn't do deduplication of modules, it was impossible to work with some projects on windows due to OS path length limit.

Reply on news.ycombinator.com