Skip to content

What "verified" means here

Why this catalog rejects high-star repositories, and the one manifest key that decides what gets listed.

A package is listed here if and only if its package.json declares a dsh.bundle manifest:

{ "dsh": { "bundle": { "patch": "./cordis.patch.yml" } } }

That is the whole gate. No exceptions β€” not even for the official @deepseek-ai scope, whose real bundles (dsh-base, dsh-web-app) declare one anyway.

Why not sort by stars?

Because stars measure attention, not compatibility. GitHub's dsh-plugin topic has been widely squatted: several of its highest-starred repositories are unrelated projects that simply added the tag. A package without dsh.bundle installs as an ordinary dependency and activates nothing, however popular its repository is.

Checking the manifest is cheap and exact, so that is what we check.

What the daily pipeline does

Verification happens against the npm registry: the manifest must declare dsh.bundle. Once a listing passes that gate, a separate daily job enriches it from its repository β€” reading stars, forks, and last-commit time from GitHub and Gitee. Enrichment is decoration, not verification: a listing is indexed on the manifest alone, and a package without a repository (or with one it does not declare) simply skips the enrichment step.

Mirror badges and star counts

A package can point at more than one repository. Each host it declares is a mirror, and the badge on the listing shows that mirror's platform β€” GitHub or Gitee. The listing's total star count is the sum across all mirrors, so a plugin mirrored on both hosts shows the combined number. The badge tells you which platform a given mirror lives on.

Why stars stay decorative

Because enrichment runs after verification, star counts never influence what gets listed. A package with no repository at all β€” zero stars, no badges β€” is just as verified as a popular one, as long as its manifest declares dsh.bundle.

Last updated 2026-08-22