Ask HN: What do you look for when reviewing 3rd party dependencies?
5 comments
License.
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.
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 actually wrote a whole blog post on this a couple years ago!
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...
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...
[deleted]
What kind of indirect dependencies it would add, who else is using it (ie. if BigCo's public code uses it, it can't be that bad), is it actively maintained and does it look like it will be maintained for the foreseeable future.
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.
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.
Proper documentation,especially API definitions. If it's just a few examples in the readme and I have to guess what the AmazongMetadataCobtextTypeProxy is supposed to represent, I am out.
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?