8 ms·

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 d

by kall 4y ago

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.

ramesh31 4y ago
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.
- aabbcc1241 4y ago
  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)
  - brainbag 4y ago
    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.
    - aabbcc1241 4y ago
      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
draaglom 4y ago
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
- deleted 4y ago
  [deleted]
- 14u2c 4y ago
  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.
  - djbusby 4y ago
    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
  - Aeolun 4y ago
    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.
- pragmatic 4y ago
  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.
  - adamparsons 4y ago
    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.
zkochan 4y ago
You can use pnpm without symlinks by setting node-linker=hoisted https://pnpm.io/npmrc#node-linker https://pnpm.io/npmrc#node-linker
- kall 4y ago
  That's great news! pnpm might be my answer after all.
epolanski 4y ago
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.
- pas 4y ago
  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.
eyelidlessness 4y ago
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.
geoffmanning 4y ago
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.
Aeolun 4y ago
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…
- zcmack 4y ago
  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.
  - kaba0 4y ago
    Until it breaks on a fresh install? Reproducibility is a must.
kaba0 4y ago
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)
- rplnt 4y ago
  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.
- edzillion 4y ago
  rimraf is your friend

by kall 4y ago

ramesh31 4y ago

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.

aabbcc1241 4y ago
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)
- brainbag 4y ago
  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.
  - aabbcc1241 4y ago
    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

draaglom 4y ago

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

deleted 4y ago
[deleted]
14u2c 4y ago
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.
- djbusby 4y ago
  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
- Aeolun 4y ago
  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.
pragmatic 4y ago
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.
- adamparsons 4y ago
  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.

zkochan 4y ago

You can use pnpm without symlinks by setting node-linker=hoisted https://pnpm.io/npmrc#node-linker https://pnpm.io/npmrc#node-linker

kall 4y ago
That's great news! pnpm might be my answer after all.

epolanski 4y ago

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.

pas 4y ago
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.

eyelidlessness 4y ago

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.

geoffmanning 4y ago

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.

Aeolun 4y ago

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…

zcmack 4y ago
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.
- kaba0 4y ago
  Until it breaks on a fresh install? Reproducibility is a must.

kaba0 4y ago

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)

rplnt 4y ago
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.
edzillion 4y ago
rimraf is your friend