You typical Node project

Feels like a lot of “not inventing the wheel” - which is good? There are plenty of good wheels out there.

But I don't NEED a wheel, I just need a tarp to put over this metal frame on my patio, and for some reason the tarp manufacturer attaches wheels and plane wings to it!?
- The package comes with all the bells and whistles but the final build only contains the tarp, if you import it right and tree shake it.
Until those wheels contain malware and spyware.
- Or bugs that you only work out much later on.
The problem is "I need function, library with 1000 functions has function, include." Library's 823rd function turns out to have a vulnerability.
- Enter tree-shaking.
"Yes, I'd like a wheel. I don't want to invent it. Why, of course, give me the full package of wheel, axis, rotor, engine, fuel tank, windshield, mirrors, tire, front panel, brakes. This wheel will be great for me manually spinning cotton!"
- And I have the option to spin cotton off-road on rugged terrain...so there's that...
You say that, but I've watched the JS community move from one framework and tool suite to the next quite rapidly. By my recollection, I've seen a wholesale change in popular tooling at least four times in the last decade. Granted, that's not every developer's trajectory through all this, but (IMO) that's still a lot.
- But changing frameworks is not why node_modules is so large. You don’t import Angular and Vue.
Is this why pip packages are called wheels...?
Yes, but my moon rover's wheels need to fulfill different requirements.

Why write code, when someone else already wrote it?

Why not import all code ever created by human kind just in case we might need some of it.
- I want to build a kick scooter. For that I need some wheels. So I import the well-known semi-truck framework. From that framework I take some huge wheels. They are too large and too many, but I guess I can make do with them.
  But I need to attach the wheels to one another, so I import the bridge-building-library, because they have steel bars in there.
  Lastly, to attach all of that together I import the NASA space ship framework because there's a hand welder in there, that's been deprecated years ago, but it's still rotting away in there because some important products still require the hand welder class for some entirely unrelated use cases.
- ...and then we can grind all the code ever created by human kind into a fine paste, and write a clever algorithm to regurgitate it as a squishy code slurry in response to questions about problems that the standard libraries already solved.

And this is why tree shaking exists.

What is that?
- If you import 1% of your module code, you only compile the actual used code. Tree shaking is removing dead code paths that aren't used.
- Dead code elimination but with a different name for some reason
It's great when it works, yeah.
I feel like the end result of tree shaking would be the image here https://fedia.io/m/programmer_humor@programming.dev/t/2547352/CSS-Gardening
- Gotta fix that link

the one on the right is also packages in node_modules that you're actually using and specifically requested.

Very true.

Python feels like that sometimes too. Except much more standard library which is much better than node modules.

Rust as well. Seems to just be a modern language thing.
- I sort of have a suspicion that there is some mathematical proof that, as soon as it becomes quick and easy to import an arbitrary number of dependencies into your project along with their dependencies, the size of the average project's dependencies starts to follow an exponential growth curve increasing every year, without limit.
  I notice that this stuff didn't happen with package managers + autoconf/automake. It was only once it became super-trivial to do from the programmer side, that the growth curve started. I've literally had trivial projects pull in thousands of dependencies recursively, because it's easier to do that than to take literally one hour implementing a little modified-file watcher function or something.
- At least Rust compiles down to what is used. I don't know if js has any of that, but at least with rust the final program doesn't ship tons of bloat.
also applicable to "installing modern drupal via composer".

Be the change you want to see in the world, people. Don't use any Node (or Rust or Python or Java or whatever) modules that have more dependencies than they absolutely, positively, 100%, for real have to. It's really not that hard. It doesn't have to be this way.

This applies to developers, too.
External dependencies put end users at risk, so I avoid them as much as possible. If that means I have to rethink my design or write some boring modules myself, then so be it.
- Depends on the use case, and what you mean by “external dependencies”.
  Black box remote services you’re invoking over HTTP, or source files that are available for inspection and locked by their hash so their contents don’t change without explicit approval?
  Cuz I’ll almost entirely agree on the former, but almost entirely disagree on the latter.
  In my career:
  I’ve seen multiple vulns introduced by devs hand-writing code that doesn’t follow best practices while there were packages available that did.
  I have not yet seen a supply chain attack make it to prod.
  The nice thing about supply chain attacks though: they get publicly disclosed. Your intern’s custom OAuth endpoint that leaks the secret? Nobody’s gonna tell you about that.
Too late, is_even_rs now depends on tokio
Which sounds like great, practical advice in a theoretical perfect world!
But, the reality of the situation is that professionals are usually balancing a myriad of concerns and considerations using objective and subjective evaluations of what's required of us and quite often inefficiency, whether in the form of programmatic complexity or in the form of disk storage or otherwise, has a relatively low precedent compared to everything else we need to achieve if we want happy clients and a pay check.
- Lol yeah working in enterprise software for a long time, it's more like:
  Import what you think you need, let the CI do a security audit, and your senior engineers to berate you if you import a huge unnecessary library where you only need one thing
  Tree shake everything during the CI build so really the only code that gets built for production is what is being used
  Consistently audit imports for security flaws and address them immediately (again, a CI tool)
  CI
  Basically just have a really good set of teams working on CI in addition to the backend/frontend/ux/security/infrastructure/ whatever else teams you have
- Saying "we can't in practice reduce the complexity of our dependency tree because we need happy clients and a pay check" is like saying "we can't in practice turn on the propeller because we need to get this airplane off the ground".
cries in legacy systems

I used to struggle with this, until I realized what's really going on. To do conventional web development, you have to download a zillion node modules so you can:

Build one or more "transpilers" (e.g. Typescript, Sass support, JSX)
Build linters and other SAST/DAST tooling
Build packaging tools, to bundle, tree-shake, and minify your code
Use shims/glue to hold all that together
Use libraries that support the end product (e.g. React)
Furnish multiple versions of dependencies in order for each tool to have its own (stable) graph

All this dwarfs any code you're going to write by multiple orders of magnitude. I once had a node_modules tree that clocked in at over 1.5GB of sourcecode. What I was writing would have fit on a floppy-disk.

That said, it's kind of insane. The problem is that there's no binary releases, nor fully-vendored/bundled packages. The entire toolchain source, except nodejs and npm, is downloaded in its entirety, on every such project you run.

In contrast, if you made C++ or Rust developers rebuild their entire toolchain from source on every project, they'd riot. Or, they would re-invent binary releases that weekend.

And if you made JavaScript developers use compatible versions for everything they'd riot. And also every build would fail for, like, at least a week
Boy do i have news concerning rust :p

Except in the picture on the left, someone's actually reading it.

Something's gone wrong if you're looking in the node_modules folder.

Sometimes you gotta monkey patch that library because they won’t accept your pull requests to fix that bug.
- At least you can monkeypatch it.

Wait until OP finds out about interpreters and compilers.

Off topic but what's the point of a book that thick other than novelty? Would make much more sense to just separate into volumes

You get books like that for voluminous stuff like parliament debate transcripts for an entire parliamentary term.
They're generally one-off or only a handful printed and kept as archival records.
Almost noone would ever need the physical book, it exists as a physical tome to cite/reference.
Seems like it would break quickly with use

Also C programmers using glibc

,

I should check Go's pkg folder...

Rust is like nodejs