DSH Plugins

How entries are checked

Every entry comes from three steps: crawl npm for candidates, pull the tarball and check it, then enrich and rank. Fully reproducible, no human rating.

Why not rank by stars and downloads

The first dsh package hit npm on 2026-08-10 and the repository went public on 08-13. All 719 installable plugins here were published after that — no exceptions. Social signals have had no time to form: downloads are almost all zero and stars mostly record who tweeted first.

So ranking uses structural evidence instead: whether the packaging is correct, whether the dependency ranges still resolve, whether the metadata is complete. Downloads and stars still count, but log-scaled and capped so they cannot dominate while the sample is meaningless.

The seven checks

declares-bundle
Does the package declare a config layer?

Without dsh.bundle.patch it never becomes a profile layer. It may be a library other plugins import — or an author who thinks they shipped a plugin.

patch-shipped
Did the declared patch file actually ship?

Omitting it from the files array produces no error at publish time — only at boot, when dsh cannot find it.

patch-parses
Does the patch parse into plugin rows?

We parse it as YAML — preserving cordis's !!js expression tag without evaluating it — and count the rows it inserts or replaces.

rows-resolvable
Can every row resolve on a user's machine?

The tutorial tells local developers to write an absolute path; authors publish it verbatim, so the row points at their own disk. These are dead on arrival.

entry-shipped
Is the declared entry module present?

We take the entry from exports["."], then main, then module, and look for that path in the tarball listing.

prebuilt
Does installing run a build script?

A prebuilt package executes none of its own code during install. A source-only package needs build authorization — which is permission to run its code on your machine.

client-half-shipped
If it declares a UI, did the ./client export ship?

Half the ecosystem has a browser half loaded through exports["./client"]. That output is easy to leave out of files — and then the plugin installs and boots fine while its UI never appears.

Version compatibility, separately

dsh moved 0.0.1-rc.1 → 0.1.0-rc.6 in three days. Judging whether a range still resolves has to reference the highest published version, not npm's latest tag: the dsh library packages promote current releases on next while latest still points at the first-day 0.0.1-rc.1. Comparing against latest marks every up-to-date plugin stale.

Current spread: 426 current, 38 stale, 206 declaring no dsh dependency at all (relying on host hoisting), and 48 using a wildcard range.

What the checks do not tell you

They read packaging, not code. A plugin passing all seven can still be malicious, useless, or simply bad. Checking rules out dead-on-arrival; it does not decide whether something is worth installing — a plugin runs inside the dsh process with everything dsh can reach.