dsh-plugin-market reports compatible: true for plugins that declare DSH support only via peerDependencies

[hyzyn]

dsh-plugin-market reports compatible: true for plugins that declare DSH support only via peerDependencies

Summary

The market evaluates a listed version's DSH compatibility from the top-level engines.dsh of its
market-index entry alone. For a package that declares its DSH range only in peerDependencies — the
fallback DSH itself documents — the manifest handed to the evaluator then carries no requirements at
all, so the version is reported compatible: true for every runtime version, including ones below
its declared floor and arbitrary future majors.

The rule DSH documents

dsh-plugin-manager's own tool description states the rule (dsh-plugin-manager/lib/types/tools.js):

Unmet DSH version requirements (engines.dsh, else DSH peer dependencies) block installation and activation.

dsh-app-boot's unmetRequirements() implements exactly that: it reads the top-level engines.dsh
and falls back to peerDependencies when the field is absent. (A top-level engines.dsh, when present,
short-circuits the peer list entirely — which is why a multi-cohort range has to live in peers.)

What the market does instead

dsh-plugin-market states the same intent (dsh-plugin-market/lib/types/types.d.ts):

Whether the running DSH version satisfies a version's engines.dsh, as DSH's installation check evaluates it.

But compatibilityOf() builds the manifest from the market-index entry, which has no peers to pass:

// dsh-plugin-market/lib/types/index.js — and the same helper again in dsh-plugin-market/lib/index.js
function compatibilityOf(name, version, exemptions, runtimeVersion) {
  const manifest = {
    name,
    version: version.version,
    ...version.engines.dsh === undefined ? {} : { engines: { dsh: version.engines.dsh } }
  }
  const issue = evaluatePluginCompatibility(manifest, exemptions, runtimeVersion)
  if (issue === undefined) return { compatible: true }
  return { compatible: false, runtimeVersion: issue.runtimeVersion, requirements: issue.requirements, exempted: issue.exempted }
}

The index schema confirms there is nothing else available: the generated declaration for a listed
version is MarketVersion = { readonly version, readonly publishTimestamp, readonly source, readonly engines }
(see dsh-plugin-market/lib/typert.host.js). And MarketCompatibility.requirements is documented as
"keyed engines.dsh", i.e. the type contract itself assumes engines.dsh is the only possible
requirement source.

Why it matters

peerDependencies is the only place a range can express an upper bound. A caret range per tested
cohort (^0.1.7-rc.2 || ^0.2.0-rc.1 || …) expands to a bounded interval, so a line that has not been
adapted yet is correctly rejected until it becomes an explicit cohort. engines.dsh is a single >=
segment with no upper bound.

Reporting compatible: true unconditionally therefore drops the guarantee in exactly the case where the
declaration is strongest — and it never turns red, because it never consults the declaration at all.

Reproduction

Take any published plugin that declares its DSH support range in peerDependencies and carries no
top-level engines.dsh, for instance:

{ "peerDependencies": { "@deepseek-ai/dsh": "^0.1.7-rc.2 || ^0.2.0-rc.1 || ^0.2.0-rc.2 || ^0.2.1-alpha.1 || ^0.2.1-alpha.2" } }

Evaluating that package with the host's own evaluatePluginCompatibility at runtime 0.2.1-alpha.5:

runtime	market path (index entry → engines.dsh only)	with peerDependencies passed through
0.1.6-rc.5	compatible	incompatible
0.2.1-alpha.5	compatible	compatible
0.3.0	compatible	incompatible
1.0.0	compatible	incompatible

The market reports the version compatible even for a runtime below the declared floor.

Minimal check (host runtime 0.2.1-alpha.5):

import { evaluatePluginCompatibility } from '<host>/@deepseek-ai/dsh-app-boot/lib/index.js'
const PEERS = '^0.1.7-rc.2 || ^0.2.0-rc.1 || ^0.2.0-rc.2 || ^0.2.1-alpha.1 || ^0.2.1-alpha.2'
const entry = { name: 'p', version: '1.0.0', peerDependencies: { '@deepseek-ai/dsh': PEERS } }
// what the market builds today (no top-level engines.dsh → nothing to pass):
evaluatePluginCompatibility({ name: entry.name, version: entry.version }, {}, '0.3.0')            // undefined = compatible
// with the peer range carried through:
evaluatePluginCompatibility({ name: entry.name, version: entry.version, peerDependencies: entry.peerDependencies }, {}, '0.3.0')  // reports the requirement

Suggested fix

1. Short term — carry the requirement sources through the index: add peerDependencies (or a
   canonical resolved-requirements field) to MarketVersion, and pass it into
   evaluatePluginCompatibility in both compatibilityOf() copies so the market really does evaluate
   "as DSH's installation check evaluates it". Index producers must emit the field.
2. Also — once peers can participate, widen the MarketCompatibility.requirements contract from
   "keyed engines.dsh" to "keyed by requirement source" (the key is already whatever the evaluator
   returns).
3. Root cause worth addressing — the rule now has three implementations (dsh-plugin-manager,
   dsh-app-boot, dsh-plugin-market) and one of them is partial. Extracting a single shared
   requirement resolver (e.g. pluginRequirements(manifest)) and having all three consume it would stop
   them drifting apart again.

Environment

• DSH 0.2.1-alpha.5, macOS, @deepseek-ai/dsh installed globally.
• Relevant files: dsh-plugin-market/lib/types/index.js (compatibilityOf),
  dsh-plugin-market/lib/index.js (same helper), dsh-plugin-market/lib/typert.host.js
  (MarketVersion schema), dsh-plugin-market/lib/types/types.d.ts (MarketCompatibility), versus
  dsh-plugin-manager/lib/types/tools.js (the documented rule),
  dsh-plugin-manager/lib/index.js (fetches engines and peerDependencies),
  dsh-app-boot/lib/index.js (unmetRequirements).

[argszero]

The reading is real — compatibilityOf() (packages/boot/plugin-market/src/index.ts:349-353) does build the manifest from the index entry alone, and when engines.dsh is undefined it hands evaluatePluginCompatibility a { name, version } with no requirements, which returns undefined and becomes { compatible: true }.

But the step between "package declares only peers" and "index entry carries no requirements" does not exist in this repository's own index producer, and the actual defect is one layer earlier: the index format's documentation and its implementation disagree, in the same commit.

1. A peers-only package does reach the market with a range

dshRange() (apps/plugin-market-generator/src/packages.ts:83) resolves the range at generation time:

• @deepseek-ai/dsh / @deepseek-ai/dsh-* peers only (DSH_PEER, :28);
• workspace:*, workspace:^, workspace:~ map to the running version and add nothing (CURRENT_DSH, :30);
• one remaining range is listed as written (:104), so your union ^0.1.7-rc.2 || ^0.2.0-rc.1 || … leaves the generator intact;
• several ranges are intersected one || alternative at a time (:98), deduplicated, and capped at 256 alternatives (:71).

So for the manifest in your reproduction, a generated entry carries that bounded union as engines.dsh, and your table's middle column does not describe it: 0.1.6-rc.5, 0.3.0 and 1.0.0 are all rejected. The entry you evaluate — { name, version, peerDependencies } with no engines — cannot come out of the reference generator. Its README states this contract explicitly (apps/plugin-market-generator/README.md:56).

2. The real disagreement is in the format note

The note that shipped with the format (3de3a977e0, 2026-10-14) says the opposite of the code in four places:

• engines and engines.dsh are listed as required — .agents/notes/implemented/feature/2026-10-02-plugin-market-index-format.md:139-140, and :140 adds "copied unchanged";
• :158 — "There is no peer fallback or range synthesis";
• :204 — "no fallback, workspace mapping, or range intersection is needed";
• :225 — "Generator and validator refuse missing, blank, and invalid engines.dsh".

The implementation does the other thing:

• the validator makes the field optional and fills {} — packages/util/plugin-market-index/src/index.ts:251 (optional(object, 'engines', …) ?? {});
• the type documents that absence means any version — packages/util/plugin-market-index/src/types.ts:62;
• the user guide rows engines.dsh as required = no, absent means any — docs/user/guide/plugin-market.md:135;
• the generator does exactly the workspace mapping and range intersection :204 calls unnecessary.

Only the last bullet is a deliberate design change; the other three are the format quietly becoming permissive. The consequence is what you observed: on a hand-written or third-party index — indexes are arbitrary configured URLs (PluginMarket config indexes) — omitting engines is legal and means "any DSH version", so the market's compatible: true is the implemented format working, not the market discarding a requirement it received.

One more mismatch while you are in there: the range's provenance is not carried. When engines.dsh was synthesized from peers, MarketCompatibility.requirements is still keyed engines.dsh (packages/boot/plugin-market/src/types.ts:53), so a diagnostic can name a field the author's manifest does not contain.

3. Suggested repair, and why not the peer-carrying one

Carrying peerDependencies into MarketVersion and re-resolving in compatibilityOf() puts a second resolver in the reader while the generator keeps its own — the drift you list as root cause #3, made worse, and it contradicts :158/:204 outright. Two coherent repairs instead, pick one:

1. Make the format match the note. Require engines in marketVersion() so an omission is a validation error; producers synthesize the way dshRange() already does. Then a listed version can never silently mean "any DSH version" and your unconditional compatible: true becomes unreachable.
2. Make the note match the format. Delete "no peer fallback or range synthesis" (:158) and "no fallback, workspace mapping, or range intersection is needed" (:204), mark engines optional as the guide already does, and state that the reference generator's fold is the synthesis — with the 256-alternative cap — while the reader performs none.

Either way, :140's "copied unchanged" needs to go: for a peers-only package the listed range is a resolved value, not a copy.

4. Severity, honestly bounded

The listing is a claim; the install gate is truthful. For a registry spec, the pre-install lookup asks for name version engines peerDependencies (packages/boot/plugin-manager/src/operations.ts:178), evaluates that manifest (:345), and refuses the whole run with "nothing was installed" before pnpm starts (:352). The installed manifest is checked again when the profile loads (packages/boot/app-boot/src/profile.ts:760). So the failure is "the market offers a version that installation then rejects" — a picker and trust defect, and a false negative for versions that should have been hidden, not an install hole.

Your point that engines.dsh alone cannot express a bounded multi-cohort range is right for author-declared engines; with the fold, the bounded union is expressible today, because the generated engines.dsh is a resolved range.