>If it's outside your core competency, you can't really judge if a dependency is well-written.
Of course you can. I can not understand the details of something like the webextensions surface area, but still can look at the polyfill and understand that it's well written, that the tests aren't useless, that the popularity isn't faked, and that the maintainer is worthy of trust.
Nothing is foolproof, but I'd be much more willing to put things that I don't fully understand into someone else's hands who claims to have a lot of experience and has a lot of support from people who do understand that thing. Especially when the alternative is to trust myself who verifiably doesn't understand the thing.
>How much time are you going to spend researching and vetting the code and the development "team" for that "seemingly trivial" dependency?
That's a really good question! For me it depends on the project. A core project which has access to a lot of PII or is an important part of our infrastructure, i'm going to spend quite a while vetting a dependency. I might see what else the author has written, I might see how they release, how long they've been in the game, how their tests look, past PRs and issues, release cadence, backwards compatibility, and more. For an extra utility that is not critical? I might spend like 15 minutes, or even less depending on what it is doing and how widespread it's usage is. Looking at the chances of me getting a malicious developer or a very broken update that I didn't test against or see is much smaller than the chances that I'll write a bug and not test it, or I'll not fully understand a domain and will add subtle bugs into it, and won't even know how to test it correctly.
>Other developers.
And that's a risk that many are willing to take quite often. You can't completely rid yourself of dependencies. You can't 100% vet all 3rd party code, and you can't run entirely on first party code. It's not possible. So you trust some things here and there, you lock down dependencies so they don't update unless you say to, you review things and limit the scope of permissions. All things you should be doing anyway. Yes, it's a tradeoff, but it's one that the vast majority of code I've written is more than safe to make, especially when the author of a library is also the author of the browser it will be running in...
>You start with one little dependency for one use-case, you end up with hundreds if not thousands of dependencies. You realistically have no capacity to deal with this in a diligent manner.
But we do! That's what dependency managers are for! I can seamlessly replace dependencies, even several layers deep. I can scan and get diffs on changes, I can easily audit the dependency tree to determine if known vulnerabilities are found and either remove the library or update it. Again, it won't work in 100% of cases, but you aren't going to write 100% correct code yourself either.
>One could argue that by using "modern Javascript" with its pathological reliance on micro-dependencies, one has already given up control to the hive of random developers anyway, so one more dependency wouldn't hurt. I probably would agree with that.
Using 3rd party dependencies is a far cry from "giving up control to the hive of random developers". Just like how you using a browser to post this comment which relies on a compiler which uses tools written in python which relies on a python interpreter which itself relies on another compiler which relies on OS libraries which rely on more and more and more isn't trusting the "hive of random developers" either. There are checks, there are audits, there are tools to manage that at just about every step. Javascript has them as well.
There's being careful, and there's being paranoid. Sometimes paranoid is needed, and I do actually agree with a lot of your arguments if they apply (For the love of god don't use one-line dependencies, don't use dependencies written by an author with an agenda who has shown themselves willing to delete/maliciously-break packages, don't just add dependencies without any review or oversight or testing), AND I do agree that the JS ecosystem takes it a bit far (although I'm not fully on-board with if it's a bad thing entirely yet), but don't just throw out statements like "a little copying is better than a little dependency". That's how you get dogmatism which just swings the pendulum in the other direction and we end up with unmaintainable statically-compiled messes with vulnerabilities that can't be found and patched on any realistic timeframes.