Repository navigation
[key packages] High Impact Packages #143
Description
Split 2/3 of #105
We have to to choose a larger group of high impact packages to implement the same practices and standards developed in conjunction with the Pilot Packages.
To choose this group of packages, we need to define the right formula to find who need help first.
The starting list of criteria for ranking is:
➕ = higher value increment the priority assigned
➖ = lower value increment the priority assigned
| Criteria | Evaluation for priority |
|---|---|
| Number of downloads | ➕ |
| Number of downloads of their full dependency tree✨ | ➕ |
| Most depended-upon packages | ➕ |
| Number of dependencies | ➖ |
| Test against Node.js versions | ➕, less is to seek and understand why |
| Old dependencies | Less are to seek and understand why. "old" is managable or do we have many false positive? |
| Deprecated dependencies | ➖ |
| Open issues | ➕ - only if labelled as confirmed bug or bug |
| Is it maintained by a company? | They want help? |
| Last activities | More recent: ➕ |
✨ During this process, we should also check if one of those dependency is on an older major and why.
What to discuss here
- We need to complete the criteria list and define the evaluation of the criteria itself
Activity
dominykas commentedon Jan 30, 2019
Should the high number of [old] deps be more of a case of "seek and understand why"?
ljharb commentedon Jan 30, 2019
What makes a dependency “old”?
Eomm commentedon Jan 30, 2019
I think that a module could be considered old when there is a newer version (at least minor/patch) or it has dependencies module deprecated.
And, as @dominykas points out, "seek and understand why" could fit better: maybe the updated lib doesn't support old versions of node.
I wonder if need more help who have dependencies updated or not 🤔
ljharb commentedon Jan 30, 2019
Certainly when it's deprecated, it's "old" - but I continue to maintain all major lines of
qs, so v3 isn't any "older" than v6; it's just missing some breaking changes.TheHollidayInn commentedon Jan 31, 2019
For "Open issues" - is higher better because it means it is active?
mhdawson commentedon Jan 31, 2019
Once we have general agreement I think getting the list that would be the top 10 for these would be a good way to validate them.
Eomm commentedon Jan 31, 2019
@ljharb Yeah, maybe I have understood what you say. Could you suggest criteria to understand these cases? Otherwise, I would treat that as "false positive". I really don't know how many could be these case 😅 I trust of your experience.
@TheHollidayInn I think that high usage of the module and high open bugs means a high level of help needed, but you pointed a good question: should we also consider if the package is "active"?
ex: less time has passed from the last commit is better
ljharb commentedon Jan 31, 2019
I think almost every criteria we come up with is likely to be a false positive, and false positives are a very dangerous thing for "best practices" we want to evangelize.
Certainly getting a concrete list based on the latest list of criteria is a good start to evaluating them.
wesleytodd commentedon Jan 31, 2019
@ljharb I agree we need to avoid this for the long term. But for the stage, which this issue is tracking, the goal is to hand pick modules. So the above guidelines should only be the start, manual effort will be necessary to decide in the end, thus helping us avoid "false positive" indicators.
Other than that, we should add that we need to reach out to the maintainers to have them agree to participate and give feedback. If they are not willing that is an automatic disqualification :)
mcollina commentedon Feb 2, 2019
I would remove the term "better" as it might create bad feelings in maintainers.
tomByrer commentedon Mar 25, 2019
May I suggest adding how frequent a project is downloaded via a CDN, such as jsDelivr? Several packages there are downloaded over a billion times per month, but jsDelivr has several layers of caching so npm.com will very rarely see those hits.
Eomm commentedon Mar 25, 2019
Nice question, because till now we had evaluated only the official npm registry.
I need to study more the context because my first thought is that it could be out of scope.
We are in trying to help the modules that run in node.js environment, but the modules download via cdn live in the browser for what I know (and a fast search it seems that jsDelivr doesn't expose a registry).
Tell me if I'm wrong
tomByrer commentedon Mar 27, 2019
Thanks for your consideration @Eomm .
JsDelivr used to use GitHub as a file repo, but was unmanageable (eg ate half of a local HD).
It duplicates npm & GitHub, not sure automatically or on-demand, but I assume "Load any project hosted on npm" means all one way or another.
npm is used for front-end projects often; see how many hits jQuery & Bootstrap have? Granted those are well maintained now, but likely there are some with 10_000+ hits/mo that might skew your numbers. The 98th ranking, Foundation, had 454k hits last month.
jsDelivr has big clients listed on their front page. cdnjs many more users, & unpkg.com is getting some ranking also.