dsh pm — the plugin manager DSH should have shipped with
dsh pm is the command group for DeepSeek Harness that closes the discovery → install → manage loop around the official dsh plugin flow: search the awesome list / GitHub topic / npm keyword, install from npm or GitHub with one command, list what's installed per profile, check for updates, and audit everything with doctor.
It is deliberately a thin, honest layer over the documented install mechanism: it never hand-edits a
profile's cordis.yml. It drives dsh plugin --profile <p> add|remove through the installer and records
its own side-band state (a plain JSON file), so it can list, update, and audit — and if the official flow changes, one adapter changes, not four packages.
dsh pm search memory → discover
dsh pm install dsh-memory → install into the configured profiles
dsh pm list → what pm installed, per profile
dsh pm update dsh-memory → reinstall if a newer version exists
dsh pm doctor → audit manifests, patches, sources, driftInstall
This package is the pm command group itself. Install it into the profile you run dsh pm … from:
dsh plugin --profile default add @dsh-pm/cli # npm (when published)
dsh plugin --profile default add github:Jesse-njx/dsh-plugin-manager # or: from the monorepoThen invoke it:
dsh --profile default pm search memory
dsh --profile default pm install dsh-memoryThe bundle patch also registers pm as a web-UI slash command (/pm search memory), so it works from the chat input as well.
Config
The config block is the PmConfig shape (spec §5.1), validated by the schemastery schema exported as Config. All fields have defaults; the block below shows the documented values:
# in the profile's cordis.patch.yml
- id: dsh-plugin-manager
config:
registry:
awesomeUrl: https://raw.githubusercontent.com/awesome-dsh-plugin/awesome-dsh-plugin/main/README.md
npmKeyword: dsh
profiles: [default] # which profiles install targets go into
stateFile: ~/.dsh/pm/plugins.json
gitInstall: { depth: 1, build: true }| Field | Default | Meaning |
|---|---|---|
registry.awesomeUrl | the awesome-dsh-plugin README URL | discovery source 1 |
registry.npmKeyword | dsh | npm keyword search term |
profiles | ['default'] | target profiles for install |
stateFile | ~/.dsh/pm/plugins.json | pm's own side-band state |
gitInstall.depth / build | 1 / true | passed to the installer for GitHub refs |
Commands
| Command | Behavior | |---|---| | dsh pm search <q> | search the merged registry; table of name, source, stars, category, description | | dsh pm install <name> | resolve and install into the configured profiles; prints resulting rows | | dsh pm remove <name> | uninstall from every profile the state mentions | | dsh pm list | state rows grouped per profile: version, source, enabled, last checked | | dsh pm update [name\|all] | check latest (npm dist-tag or GitHub HEAD); reinstall when newer | | dsh pm doctor | read-only audit; exits non-zero when any finding is an error |
Doctor
dsh pm doctor audits every installed plugin:
- (a) the manifest still parses (
ManifestParser), - (b) its
dsh.bundle.patchfile resolves on disk, - (c) its repo/npm source is still reachable,
- (d) version drift (installed vs latest),
- (e) duplicates / conflicting entries across profiles,
- (f) unmanaged plugins present in a profile but absent from the state store,
- (g) registry reachability overall.
Doctor is read-only: it reports ok / warn / error findings with a one-line fix hint and tells you the exact dsh pm command to run — it never repairs.
How it works
dsh pm install <name>
→ @dsh-pm/installer resolves the source (npm / github / registry)
→ run seam shells: dsh plugin --profile <p> add <ref>
→ @dsh-pm/core StateStore records the row (atomic temp+rename JSON)
dsh pm list
→ installer.list() reads the state store@dsh-pm/cli is the only package that imports all three siblings (core, registry, installer); it wires them together per the frozen cross-package contract in spec §5.
Development
pnpm install
pnpm --filter @dsh-pm/cli build # tsc → lib/
pnpm --filter @dsh-pm/cli typecheck # tsc --noEmit (src + tests)
pnpm --filter @dsh-pm/cli test # node --test test/*.test.tsUnit tests cover command registration on a real Cordis ctx.commands (register/dispose restores the stock surface), output-rendering goldens, and doctor exit-code behavior over fake store + registry. The cross-package flow (real installer + real dsh CLI against a temp DSH_HOME) lives in the integration-test package.
License
MIT