It's not that hard. You just need to think of dependencies as something that has non-zero benefits and non-zero costs. The problem is that, as usual, whereever you've got a "zero" showing up in your cost/benefits analysis, you're overlooking something. Sometimes it's minor and negligible stuff, but sometimes it's not. Act accordingly.
One thing that I believe we will come to a consensus on is that there is a certain fixed cost of a dependency, analogous to the base cost of a physical store to manage the stock of anything that appears on the shelves no matter how cheap the individual item may be, and that a dependencies will need to overcome that base cost to be worthwhile. I suspect that the requisite functionality is generally going to require in the low hundreds of lines at a minimum to obtain, and that we're going to see a general movement away from these one-line "libraries".
I say generally more than a few hundred lines because there are some exceptional cases, such as encryption algorithms or some very particular data structures like red-black trees, where they may not be a whole lot of lines per se, but they can be very dense, very details-oriented, very particular lines. Most of our code is not like that, though.
Do you mean creating libraries that are flexible and partitioned well for future needs? I do find that hard and almost no library maker I know of gets it right the first time. Analysis of current needs is difficult; analysis of future needs is extra difficult. Experience helps, but is still not powerful enough. The future continues to surprise the heck of out me. Tell God to slow things down ;-)
No, I mean that it's not that hard to do some due diligence when picking a dependency. You just need to get over the idea that it's something you don't need to do.
No, you're not going to read every single line, but you ought to be running through the basics outlined by Russ in his post. If you're being paid to code and you're not doing those basics, you're being negligent in your professional duty.
And knowing the internet and its inability to deal with nuance, let me say again, no, it's not trivial. But it's not that hard, either. If a dependency is worth bringing in, it's bringing you enough value that you ought to be able to spare the effort of doing the basic due diligence.
One thing that I believe we will come to a consensus on is that there is a certain fixed cost of a dependency, analogous to the base cost of a physical store to manage the stock of anything that appears on the shelves no matter how cheap the individual item may be, and that a dependencies will need to overcome that base cost to be worthwhile. I suspect that the requisite functionality is generally going to require in the low hundreds of lines at a minimum to obtain, and that we're going to see a general movement away from these one-line "libraries".
I say generally more than a few hundred lines because there are some exceptional cases, such as encryption algorithms or some very particular data structures like red-black trees, where they may not be a whole lot of lines per se, but they can be very dense, very details-oriented, very particular lines. Most of our code is not like that, though.