"is this package 'healthy'?" is a good line of thought, but the proposed metrics are all less useful than just opening the source on Github or unpkg.com and giving the source code a quick skim read.
If it looks too scary for you to maintain, you shouldn't take it on as a dependency.
> It’s not really a technical problem, but mostly a social one.
You're right! That works great for the package itself, and it's what I do. But will you also chase down and open on github all that package's dependencies, and their dependencies, etc? It is that, more recursive problem that I'm trying to point at. If you are content to trust that the package maintainer chose their dependencies wisely, then this probably won't seem like a big deal -- and that's ok! Different projects have different requirements for how they assess third-party code.
unpkg may work, but I doubt many people know of that.
Most people are going to reach for Github, and let me warn you right now: the packages on NPM are not necessarily from the source code you may find on Github. I've run into this a number of times, where a package exists on NPM that has an entirely different Github repo than you may expect. In addition, people can freely create NPM packages that look official but are not. It's a huge security hole.
If a package contains only minified JS, then you're not going to be able to audit it. And it goes without saying, if you didn't minify the code yourself, how well do you really trust it in the first place? It's a huge tower of trust, and NPM solves none of it.
If it looks too scary for you to maintain, you shouldn't take it on as a dependency.
> It’s not really a technical problem, but mostly a social one.
This is absolutely correct.