I don't. I'd rather trust the tens of thousands of developers working on the core language and core stdlib, than on a dependency some random guy in Albania maintains on his spare time.
Or in the case of the JS ecosystem, you might only use established dependencies, which in turn use dozens more which in turn use dozens more, and the probability that there's a dependency some random guy in Albania maintains very quickly approaches 100%.
If you have a problem with library written and maintained by a random guy in Albania you have the option of not using it. If a functionality is so niche that you can only find one fit in the entire npm ecosystem, I doubt this functionality will ever make it to the standard lib of a non-node runtimes.
Personally I like dependencies written and maintained by a random guy in Albania on their spare times. And I would use it when making fun stuff at home. I might even open an issue or a pull request. Dealing with a random guy in Albania sounds way more fun then dealing with a language committee in Silicon Valley.
How many people audit their dependency authors more than 1 level deep? That's the problem: I know who wrote all of my first level dependencies (react, react-router, redux, reacstrap, etc). I don't know who wrote _their_ dependencies, and the 3rd level, 4th level. And I don't think anyone has the time to adequately evaluate that every time a dependency's version gets bumped given how deep the graph goes.
I'm like you. I want as few dependencies as possible. I liked this about PHP: You could get very far without any dependencies at all.
For a toy project, pull in some dependencies. For a more serious project that requires to do due diligence on every dependency you pull in, it gets annoying very quickly.
Also, I kinda dread all the fast-changing version numbers in the JS ecosystem.
There is nothing stopping you from looking at their code and, after vetting it, copying the code and pasting it into your own local JS files. Now you don’t have to worry about anyone tampering with it after you have vetted it.
Sure, I'll do that next time I'm at work, I'll tell the frontend dev running `npm install next` to spend the next 6 months doing a code review of the 258 dependencies in the tree. Boss will have to wait.
There's dependencies like webpack, and "dependencies" like lodash-sortby, is-number, isarray, diffie-hellman, encoding, is-negative-zero or assert. Who in good faith can argue that those are better served as standalone dependencies maintained by who-knows-who instead of being in a standard library?
I so wish someone had the balls (and good enough OpSec) to inject malware into one of those 5 lines long dependencies, causing hundreds of billions of dollars in damages, and then we'll perhaps do something about it.
In practice, you rely on libraries that are popular and/or written by someone trustworthy. "Vetting" libraries amounts to thorough tests of the complete application.
Or in the case of the JS ecosystem, you might only use established dependencies, which in turn use dozens more which in turn use dozens more, and the probability that there's a dependency some random guy in Albania maintains very quickly approaches 100%.
Have we already forgotten left-pad?