Normally (or "back in the day" rather) you'd read through the code, see if it's of "maintainable" quality in case you're gonna have to fork it, see if the code quality is at least average, the author being consistent, having good tests and so on.
But today I see people just pulling down fresh 3rd party dependencies just because their peers are using the same ones, or going by number of GitHub stars to see if it's OK to use.
If you're reviewing dependencies before using them, what kind of things are you looking for? Is there something obvious that would immediately make you reject the dependency outright?
If you're not, do you go by some other metrics or even feelings to understand if it's OK to depend on this dependency or not?
What dependencies they bring with them and their license.
Test coverage.
Whether it has sufficient backing - i.e. from a larger company or very actively and independently developed. Definitely do not look for a possibility where we have to fork and maintain it ourselves.
How does the "Issues" section look like.
Who are other users.
Where is the artefact hosted.
Exposes APIs in a way that we can easily wrap it in our app and that the wrapper part doesn't have to be complex or has to be modified specifically for this lib.
Has debugging and troubleshooting info/docs.
If the doc is too big or too complex I would preferably not touch it. I prefer libs which expose very little and are documented simply in human readable ways.
I threw out a list of 30-ish criteria off the top of my head, and linked to a few other posts with some additional lists of criteria:
https://blog.isquaredsoftware.com/2020/09/coding-career-advi...
Things like sparse documentation or stale code that does things in an "old" style aren't really signals to me. I'll gripe about it for sure but plenty of good libs have those warts.