How do you filter and audit third-party libraries these days?

Start with whether the package actually solves your problem, then look at its issue tracker. Are bug reports getting useful responses? Are the same problems being reported repeatedly without a fix?

Stars and recent commits can help you find candidates, but neither tells you much on its own. A quiet project might be stable, while a popular one can still have a backlog of neglected bugs. Once you have a shortlist, look at tests, dependency size, and the parts of the code you expect to rely on.

For routine work, boring is good. An established library that does the job without a lot of moving parts is often a better starting point than a shiny new package. That doesn't make it automatically safe, but it can narrow the search.

Sometimes the best dependency is no dependency. If the requirement is small and specific, writing a focused implementation gives you less code to review and no third-party updates to follow.

That stops being attractive pretty quickly for something as large as a framework. Generated code also needs review and tests, so it doesn't make the quality question disappear.

I'd scale the review to the risk. A small helper used in a noncritical feature doesn't necessarily warrant the same scrutiny as a library handling sensitive data or sitting in a core service.

For the latter, check the code paths you depend on, the tests around them, and the package's own dependencies. Also remember that approving one version doesn't automatically approve every future update.

People also differ on how much weight to give signs of AI-assisted development. Some treat them as a warning about quality. I'd look at the actual code and maintenance practices rather than assuming a tooling file proves the package is either good or bad.