I read an interesting article Tripping over the potholes in too many libraries. The simple rule suggest is
Never use a dependency that you could replace with an afternoon of programming
The reasons given were pretty sound - searching online takes time, reading docs to make sure takes time, connecting the wires takes time.
My general response to that is a big "ummm, maybe?"
When is the last time you estimated something would just take a few hours, and you ended up spending exactly a few hours on it?
The longer I do this gig, the more I realise that I don't actually know everything. And each day, the percentage of stuff I know out of the global cache of knowledge is getting less every day. The things that seem simple are likely only simple because I haven't tackled that problem recently, or ever.
The first time I encountered this was working with CSV files in the early 2000.
"Comma separated files? how hard can that be?"
Yep, I coded that up in an afternoon, probably less.
Then I had to handle quotes, then multiline values, then different code pages, different encodings, with and without BOMs at the start of the file.
That is an example of where I sit now. If there is even a small chance of it turning into a complicated problem, I always see if someone else has done it first. There is a large chance they have found, fixed and implemented things I haven't thought of yet.
If you choose to implement something that someone else has solved before, be prepared to support that thing for a while. Code has a habit of sticking around well past the prototype stage.
You still end up with a dependency, you are just deciding if you have a dependency you are maintaining internally, or one someone else is likely maintaining externally.