dsh-publisher-radar · Publisher Radar
A market-gap radar for DSH plugin developers — see which directions are still open before
you write the code.
It answers one question: which corners of this market are empty? Several thousand
plugins are split by category and then by topic, and every topic is tagged empty / thin /
contested / crowded, so "what should I build next" becomes something you can look at rather
than guess. Browsing the full market and copying install commands is what falls out of the
same catalog, not the point.
简体中文 · MIT · Publishing
Why
The DSH marketplace passed 6,000 plugins in 2026 and keeps growing — the panel always
shows the current count, because it reads the catalog rather than a number written here.
The bigger that market gets, the harder "what should I build" becomes. What blocks a plugin
author is rarely writing the code; it is finishing it and finding out somebody already shipped
the same thing. Today that judgement comes from scrolling the list and going on memory:
- Is this direction already taken? — names collide (five authors ship a
dsh-plugin-doctor), while the real competitor describes itself in completely different
words and never shows up in a name search.
- Is there still a gap inside a busy category? — big categories like
ui or dev hide
dozens of topics, some with thirty plugins and some with one or two.
Publisher Radar splits the catalog by topic and makes "what's empty" visible at a glance.
What you see
A sidebar entry and five model tools — all from one catalog. The topic view is the core;
the rest is supporting cast.
| Surface | What it does |
|---|
radar_gaps | The one you'll use most: which topics have 0–3 plugins, ranked so the emptiest directions come first |
| Panel「方向 · Topics」 | The same view with a UI: category → topic → plugins, four coverage levels, both sort directions |
radar_plugin | Who already took this topic, name or author — dedupe and competitor lookup |
radar_market | How big is the market, what leads, how each category is distributed |
radar_mine | My downloads, stars, catalog presence, category rank |
radar_checkup | Will this folder survive a market install? |
| Publisher Radar (sidebar) | Browse the whole market: search, category filter, paging, sort by downloads / stars / date; open one for its install command |
| Panel「设置 · Settings」 | Track your own npm packages; optional GitHub token (never required) |
Zero configuration, on purpose
Nothing below is required to use it, and there is no setup step:
- Catalog — raced across the canonical host, unpkg, jsDelivr, and the npm China
mirror (
dsh-plugin-catalog tarball). Whichever answers first wins; results are
cached six hours. Measured from a mainland network: 6.7 s when the canonical host is
blocked, 0.7 s through the mirror, 50 ms from cache.
- Stars — live from GitHub when the package has a repository (the catalog's URL, or
the one npm publishes); otherwise the catalog's snapshot. A failure falls back
silently instead of showing a broken number.
- Your plugins — read from the panel's Settings field (「设置」in the UI), or
auto-detected when the workspace is your plugin folder (a
package.json with
dsh.bundle). A local file: package that was never published still resolves — its
manifest is in the profile.
Install
dsh plugin --profile web add dsh-publisher-radar
Restart the profile → the sidebar gains Publisher Radar.
Optional config
Only when you want it:
- id: publisher-radar
config:
myPlugins: ["your-package"] # track a published plugin from any workspace
githubToken: "" # higher GitHub rate limit (or GITHUB_TOKEN)
Honest caveats
- Coverage is a lexical match over
name + description, so it over-counts
(ats hits formats). Reported 0 is trustworthy; a large number only means
"not obviously unclaimed".
- The 80 topics do not cover every plugin (about half match none). Browsing is the
full catalog; the topic ranking is for deciding what to build. Do not mix the two.
checkup judges packaging and supply-chain shape, not code quality or security.
Privacy
- Public data only, nothing uploaded.
- Writing: two files. The catalog cache (
catalog.json, 8.7 MB, six-hour TTL) and
the settings you save in the panel (config.json). No history, no session data, no
copies of anything of yours.
- A GitHub token, if you provide one, is stored in that
config.json in plain text on
this machine and is never returned by the API — only "a token is set".
radar_checkup reads the folder you point it at and writes nowhere.- The panel's data is served by your local DSH web server, same-origin,
no-store.
Development
npm test # smoke + host wiring + client (offline)
node test/smoke.mjs --catalog ../market/plugins.json # against the real catalog snapshot
npm run test:install # pack, install into a temp dir, boot it
node scripts/sync.mjs # copy into the desktop profile
test:install is the one that matters before a release: it takes the tarball a user
would download, npm installs it into an empty directory, then imports the installed
copy and asserts it registers its five tools and two routes. Packaging mistakes that
pass a source-tree test (a missing file, an absolute name: in the patch) fail here.
No build step, no runtime dependencies. lib/ ships as authored; the browser half is
hand-written plain JS (no JSX, no bundler), the same shape DSH's own panels use.
Limitations
- The catalog is a curated list, not npm itself; an unlisted plugin is invisible here.
added dates come from the catalog, so a very fresh plugin may not be dated yet.
License
MIT
