Hacker News Reader

This makes me think about the quality of the dependancy. If you could evaluate packages for things like:

* Test coverage -- that's not a metric on NPM * Code practices -- what's the review history * Issue velocity -- hard metric, lots of features vs fixes * Hygiene -- for many languages is typing enforced / validated

I'm sure there are lots of other metrics, but so many times you're just evaluating two packages based on "star count" or "npm installs".

View on HN

Agree that this is the largest issue with code quality.

Knowing when and which package to import, given the incomplete data points we have now.

Stars/downloads are a popularity contest. At some point, people mostly vote for the candidate who is most likely to win (causing this to be self-reinforcing) , not the one with the best ideas.

The stability+sustainability of the development team, the signals of consistent quality (eg. Code linting, code quality audits, bug bounty program participation, public security audits, good design documents, automation of builds, testing methodology and test coverage).

Factors for me are: 1. how hard will it be to remove/replace this package in the future? how much coupling does it introduce? 2. how likely will it be that this is deprecated/unmaintained in the future

Reply on news.ycombinator.com