While this is an extreme case of course, packages by themselves are quite cheap (apart from installing times), and usually if the author tries to keep the dependencies in check it doesn't really create a mess.
This is why funny stories like leftpadgate can happen.
Relying on an external dependency is a net win if and only if the time gain overcomes the loss of control.
Maybe regrouping all these tiny libraries under an umbrella project (lets call it node-utils or js-tinytools or whatever) will mitigate the problem?
This project will not have any external dependency though will be used by most of the projects and ergo might be watched with much more attention.
Having them separate like this at least means that if one library doesn't implement things 'right' you can switch to another easily.
Look at python (or ruby)'s standard library, it's awesome, and of high quality (most of the time, see urllib/requests for a counterexample).
Everybody should remember this
I had a problem with running out of inodes on my server because of the massive number of files that end up in node_modules for even a smallish project.
Did you write about it somewhere?
Turns out, the combination of vboxsf and ntfs masquerading as a linux filesystem is not without bugs-
Sometimes, the directory depths that npm reached caused the filesystem to "soft crash", where it would just fail to do operations on files, meaning you had to run `npm install` a few times to actually grab all the dependencies.
Other times, it caused the host machine to blue screen.
One of the times this happened, it had the side effect of irreversibly corrupting my favourite programming font (Fira Code) for all JetBrains IDEs on that Windows install.
Not so much a problem now I'm not being forced to develop in Windows. But even though I dug up bugs in unrelated pieces of software / the host OS kernel, npm was still pushing that software to the limits with that crazy recursive directory structure it was attempting to build.
You don't get this shit with python!