One of the biggest challenges for discovery of modules in the Deno eco-system is identifying suitable packages. When browsing modules, modules are currently only listed based on GitHub star count. We need a better scoring metric. Inspired by npms.io here is a work in progress proposal for the metric.
The metric would have three aspects to it, which have several contributing data points:
Popularity
Documentation views (on doc.deno.land and soon on deno.land/x) - high weighting
Should be a sliding window. 30 days?
Usage count (from deno.land/x) - medium weighting
Should be a sliding window. 30 days?
GitHub stars - low weighting
Quality - this is a tricky metrics, because there are few absolutes around quality that @crowlKats and I could come up with, this clearly needs more discussion. In almost every case it feels like something where everything starts at 0 and gains quality points as more of the "tick list" is true.
Coverage of JSDoc on exported symbols - a high level
Has a README and license
passes deno fmt and deno lint (the challenge here is what should be considered code to include in this)
deno test --coverage high
a deno.json/deno.jsonc exists
an identifiable entry point ({mod,lib,index}.{ts,tsx,js,jsx,mjs})
Maintenance - this is also somewhat subjective too and needs refinement
Ratio of open issues vs. total issues
The time it takes to close issues
direct and indirect usage of std library being "current" or excessive duplication of versions of std library
Commit frequency
An overall score would be derived from this to influence the sort order. Currently we think only popularity is easily deliverable, and so the initial weighting would be Popularity 1, Quality 0, Maintenance 0. We would weight these different in the future.
One of the biggest challenges for discovery of modules in the Deno eco-system is identifying suitable packages. When browsing modules, modules are currently only listed based on GitHub star count. We need a better scoring metric. Inspired by npms.io here is a work in progress proposal for the metric.
The metric would have three aspects to it, which have several contributing data points:
deno fmtanddeno lint(the challenge here is what should be considered code to include in this)deno test --coveragehighdeno.json/deno.jsoncexists{mod,lib,index}.{ts,tsx,js,jsx,mjs})An overall score would be derived from this to influence the sort order. Currently we think only popularity is easily deliverable, and so the initial weighting would be Popularity 1, Quality 0, Maintenance 0. We would weight these different in the future.
Ref denoland/dotland#2081