I will write here that you should use libraries. Then next week you will see me complain about an app having two million dependencies... Here's how I find balance: I try to use "battle tested" code rather then writing my own. eg. other people's libraries. But I try to keep the dependencies down. If a package has 10,000 files I rather just rip out the functionality I need. (So I hate when you can not do that, eg. if every function in the code is dependent on every other function.) Often I find issues and are either too lazy to send a "merge request" or the maintainer refuse to merge it. So in many dependencies I often end up using my own fork.

Dependencies are a two edges sword. It's good that you get security updates. But if you can't review all the changes, security issues can also sneak in. Like if someones npm account get hacked and the hacker sneaks in a remote shell or backdoor. Those can be hard to find if you got millions of dependencies which get tons of updates every day. So I usually lock down dependencies, and NPM becomes a fancy tool for copy/pasting.

Every npm library has its own copy of its dependencies. This duplication is what causes the huge number of dependencies.

This duplication is necessary because npm is not a curated software distribution designed to work as a cohesive system. Anyone can push software to npm. As a result, there are packages that depend on different versions of the same library and they must have their own individual copies of the dependency in order to work. This isn't the case in a Linux distribution with maintainers: there's one instance of the package that's shared by all other packages.