[swatcoder]

It’s common, but also absurd, to hold your own teammates to a higher standard than you do some internet rando contributing a big block of code to your project.

With exception of a handful of “pillar” dependencies used throughout the industry, you should be reviewing your dependencies with the same eye for detail that you bring to pull/merge reviews in your own organization. And you should do it again every time you explicitly tell your package manager to reference a new version.

If you care about the quality of your own project, it doesn’t matter how many stars there are, or the commit frequency, or the responsiveness to issues. What matters is that the code is legible, that it meets your own standards of quality and reliability, and that you understand in detail what it’s doing.

If you can’t do that because a dependency is too large or fast-churning to review, then you should consider whether its actually suitable for your project. Often, in these cases, you’ll remind yourself that you only need 1% of what the dependency provides and that it’s actually less work and better for your skill development to tackle that 1% on your own or with a more narrow dependency that you can properly vet.

But of course, your product manager probably won’t have the patience for any of this, and your colleagues will look at you like you’re a paranoid freak. And that’s why software quality is garbage now and getting constantly worse.