[Bug] pnpm 'missing peer' warnings on dsh plugin add are false positives — peers resolve via the shared fallback

[ackalker]

Symptom

Running a plugin install on a profile emits noisy pnpm warnings that are misleading:

$ dsh plugin --profile web add @deepseek-ai/dsh-web-search-exa@0.1.2-rc.1
[WARN] Issues with peer dependencies found. Run "pnpm peers check" to list them.
[WARN] missing peer @deepseek-ai/cordis
[WARN] missing peer @deepseek-ai/dsh-web
[WARN] missing peer @deepseek-ai/dsh-launch-environment

The same command for dshmarket (or for these peers in a different install order) stays quiet. Both plugins then work normally.

Finding: the peers are not actually missing

The peers pnpm flags (@deepseek-ai/cordis, @deepseek-ai/dsh-web, @deepseek-ai/dsh-launch-environment, and for dshmarket also @deepseek-ai/dsh-settings and @deepseek-ai/schemastery) all resolve fine at runtime. They are provided by the shared installation fallback at $DSH_HOME/profiles/node_modules, which Node resolves through its ordinary parent-walk when a plugin is loaded from $DSH_HOME/profiles/<profile>/node_modules.

Verified: every one of those packages is present in $DSH_HOME/profiles/node_modules/@deepseek-ai/, and both plugins load and function after the warning.

Root cause

The warning is a false positive produced by two interacting facts:

1. The profile's pnpm-workspace.yaml is generated automatically by initProfile (packages/app-boot/src/profile.ts) and sets autoInstallPeers: false with nodeLinker: hoisted. With autoInstallPeers: false, pnpm does not install peer dependencies and instead reports them as missing.

2. The shared fallback $DSH_HOME/profiles/node_modules lives outside the profile's pnpm workspace (the workspace is packages: ['.']), so pnpm's install-time peer graph cannot see it. pnpm stops at the workspace root and reports the peers as absent, even though Node finds them at runtime.

The design intent (see the comment in profile.ts) is that every plugin shares the installation's single cordis instance rather than a duplicate copy. Keeping autoInstallPeers: false is what preserves that; the warning is the side effect of pnpm being unable to see the fallback that makes the design work.

Note on the inconsistent behavior: in an isolated install both dshmarket and @deepseek-ai/dsh-web-search-exa warn. Whether a given dsh plugin add prints the warning depends on the transient pnpm store/graph state at that moment (what is already cached and linked), which varies by install order and pnpm version. Neither case indicates a real problem.

Why this is a "trick" and why it bothers users

The current approach relies on autoInstallPeers: false + silent runtime parent-walk: pnpm is put into a state where it reports peers as missing that are in fact present, and dsh plugin add is a thin forwarder (spawnSync("pnpm", args, {stdio: "inherit"})) that relays that output verbatim. The peers resolve correctly, but pnpm is misled and the user is handed a warning that looks like a broken install.

Suggested fix (verified)

pnpm has a first-class, honest setting for exactly this: peerDependencyRules.ignoreMissing. Add it to pnpm-workspace.yaml:

peerDependencyRules:
  ignoreMissing:
    - "@deepseek-ai/cordis"
    - "@deepseek-ai/dsh-web"
    - "@deepseek-ai/dsh-launch-environment"

Or, to cover the whole harness scope in one line:

peerDependencyRules:
  ignoreMissing:
    - "@deepseek-ai/*"

I tested this against pnpm v12.3.4 (the version the profile uses). With it set:

• pnpm install prints no [WARN] line.
• pnpm peers check reports "No peer dependency issues found."
• Resolution is unchanged: autoInstallPeers: false is kept, so no duplicate cordis is installed and the single-instance invariant is preserved.

This replaces a covert state with an explicit declaration of intent ("these harness peers are provided by the shared fallback, not by pnpm"), which is both more correct and easier to understand.

Open questions for the maintainers

• Glob ("@deepseek-ai/*") vs. an explicit list. The glob is future-proof and one line, but it suppresses missing-peer warnings for any @deepseek-ai peer. In the harness's controlled design every harness peer resolves via the fallback, so nothing real is masked; an explicit list is more precise but must be maintained as the peer set grows.
• Existing profiles already wrote their pnpm-workspace.yaml on first use, so they would need a manual edit or a one-time regen to pick up the new block. Should initProfile also heal existing profiles?
• Whether the peers should instead be declared so pnpm installs them. This is deliberately avoided because it reintroduces the duplicate / dual-package-hazard the shared fallback exists to prevent.

[argszero]

Verified against master d347e70390 — your source trace is accurate, and peerDependencyRules.ignoreMissing is the honest fix.

Source confirmation (packages/boot/app-boot/src/profile.ts:183-189): PROFILE_PNPM_WORKSPACE writes exactly what you found —

packages:
  - .
nodeLinker: hoisted
autoInstallPeers: false

with the design comment above it: the hoisted linker gives out-of-tree plugins a flat node_modules whose missing peers fall through to the healed profiles/node_modules fallback, so every plugin shares the installation's single cordis instance instead of a duplicate. The single-instance invariant is real and worth preserving — the duplicate/dual-package hazard this design prevents has its own long crash history in this ecosystem (bundled-vs-hoisted symbol duplication), so "just let pnpm install the peers" is correctly off the table.

On glob vs explicit list: I'd take the "@deepseek-ai/*" glob. In this controlled design every @deepseek-ai peer is meant to resolve via the fallback — that's the whole point of the healed mirror — so the glob doesn't mask anything real, and it's future-proof as the peer set grows. If you want a middle ground, scope it to the known harness peers and accept the maintenance.

On healing existing profiles — this is the one part with a real wrinkle: initProfile (:197-215) never touches existing files ("Existing files are never touched, so re-running is a no-op"), and pnpm-workspace.yaml is only written when absent. So existing profiles won't pick up the new block on their own. Options: (a) a one-time managed rewrite — version the workspace template and have the profile loader rewrite the file when the template version advances (it's a generated file, so a clean regen is safe), or (b) a dsh plugin/CLI repair command. Option (a) fits the existing "generated file, don't hand-edit" framing better than asking users to edit it manually — the file is explicitly generated, so a versioned regen is consistent with how it's treated today.

Worth a proper thread/upstream note since it's a small, self-contained change to PROFILE_PNPM_WORKSPACE + a heal path — your tested fix is the reference.