npm latest dist-tag on dsh-* plugin packages points at an older release than the CLI

[cakesmachina]

Summary

On npm, the latest dist-tag for the @deepseek-ai/dsh-* plugin packages points at
0.0.1-rc.1, while 0.1.1-rc.2 is published. 0.0.1-rc.1 sorts below every other
published version, so latest currently points backwards.

The @deepseek-ai/dsh CLI itself is tagged correctly. The result is that
dsh plugin --profile <name> add <pkg> — which resolves latest — installs plugins from a
release train older than the CLI running them, producing a tree that fails at module link
time.

Verified against the registry today:

package	latest	newest published
@deepseek-ai/dsh	0.1.1-rc.2	0.1.1-rc.2 ✅
@deepseek-ai/dsh-base	0.0.1-rc.1	0.1.1-rc.2
@deepseek-ai/dsh-acp	0.0.1-rc.1	0.1.1-rc.2
@deepseek-ai/dsh-llm-pi-ai	0.0.1-rc.1	0.1.1-rc.2
@deepseek-ai/dsh-subprocess-local	0.0.1-rc.1	0.1.1-rc.2
@deepseek-ai/dsh-app-boot	0.1.0-rc.6	0.1.1-rc.2

(Published version lists for these include 0.1.0-rc.3, 0.1.0-rc.6, 0.1.0-rc.7,
0.1.0-rc.8, 0.1.1-rc.1, 0.1.1-rc.2.)

Reproduction

dsh plugin --profile myprofile add @deepseek-ai/dsh-subprocess-local
dsh --profile myprofile

Fails with errors that do not point at the cause:

failed to import loader entry subprocess (@deepseek-ai/dsh-subprocess-local):
  The requested module '@deepseek-ai/dsh-subprocess' does not provide an export named 'SubprocessService'

failed to import loader entry llm-pi-ai (@deepseek-ai/dsh-llm-pi-ai):
  Cannot find package '@deepseek-ai/dsh-environment'

The second is the clearer tell: @deepseek-ai/dsh-environment is not published in any
version, so the resolved plugin was built against an internal-only dependency — i.e. the
wrong release entirely, not a missing install.

Workaround

Pin explicitly to the CLI's train, bypassing latest:

pnpm add -E @deepseek-ai/dsh-acp@0.1.1-rc.2 @deepseek-ai/dsh-subprocess-local@0.1.1-rc.2 ...

Declared peer ranges are correct (^0.1.1-rc.2), so only unversioned installs are
affected. That is what makes this specifically a dist-tag problem rather than a manifest one.

Suggested fix

Re-point latest on the dsh-* packages to 0.1.1-rc.2 (or publish future RCs under a
next/rc tag and leave latest on the newest stable-intent release), so that
dsh plugin add and latest agree with the shipped CLI.

Two smaller things noticed alongside

1. pnpm exits non-zero on ERR_PNPM_IGNORED_BUILDS, so dsh plugin add prints
   dsh: pnpm failed in profile directory ... after an install that actually succeeded.
   Treating that specific code as a warning would avoid a misleading failure message.

2. pnpm 11 blocks postinstall scripts by default, which skips
   dsh-subprocess-local's ensure-spawn-helper.mjs. Since npm strips the executable bit
   from node-pty's prebuilt spawn-helper, the tree installs "successfully" and then
   fails only when the agent first spawns a shell. A note in the docs, or an
   onlyBuiltDependencies hint for profile directories, would save some debugging.

Environment

• @deepseek-ai/dsh 0.1.1-rc.2, plugins pinned to 0.1.1-rc.2
• pnpm 11.22.0 via corepack, Node 22.23.1, macOS 27.0 arm64

[argszero]

Verified against the live registry today plus rc.2 (HEAD b150a55) — this is the third report of a family I have been tracking (#2763 moujf 08-17 → #3461 Metahumanz 08-20 → #4434 today), and the source has the root cause in-tree.

Independent registry check (live, today)

• @deepseek-ai/dsh — latest = 0.1.1-rc.2, next = 0.1.1-rc.2 ✅ (CLI is correctly tagged)
• @deepseek-ai/dsh-base — latest = 0.0.1-rc.1, next = 0.1.1-rc.2 ❌
• @deepseek-ai/dsh-environment — E404, not published in any version ✅

Your table is accurate, and the asymmetry is real: the CLI gets its latest moved; the plugin packages do not. That is exactly why npx dsh@latest works while dsh plugin add <pkg> (unversioned → latest) installs a broken train.

Root cause is the release script, in-tree
scripts/release/publish.ts:98-99:

// A prerelease version never takes the latest dist-tag.
const tagArgs = version.includes('-') ? ['--tag', 'next'] : []

Every release in the 0.1.x line is a prerelease (-rc.N), so every publish goes out with --tag next and latest is never advanced by the tooling — it stays frozen at whatever version was first published without a tag override. The policy was written for a stable/prerelease dual track that never materialized (there has never been a non-hyphen release to take latest). The CLI package is corrected manually after each release; the plugin packages are not. So the stale tags are not a one-off publishing mistake — they are the steady state of the current release policy.

Gate status: scripts/publish-npm-baseline.ts already carries a release manifest with per-package distTag entries and a validateDistTag() helper, but the helper only checks shape (non-empty, no whitespace, :938-940). Nothing asserts latest == newest published version across the family, so the staleness passes every gate silently — which is why it survived #2763 and #3461.

Fix refinement (beyond the one-time dist-tag op, which is necessary but will regress):

1. Release policy: when the rc line is the only track, the publish step should also advance latest — e.g. after npm publish --tag next, run npm dist-tag add <pkg>@<version> latest when no newer stable exists (or change the :98-99 policy comment to "prerelease takes latest while it is the newest release overall"). This makes the CLI/plugins symmetric by construction.
2. Gate: extend publish-npm-baseline.ts to query the registry and assert latest equals the newest published version for every package in the manifest (not just tag shape). That is the regression test this keeps failing.
3. Consumer hardening: make dsh plugin add resolve the CLI's own version train (pin @<cli-version> like your -E workaround, or prefer next when the CLI itself is an rc) so a future tag lapse degrades to a warning, not a broken tree.

Your two side notes are both real; note 2 has a hidden family connection.

1. ERR_PNPM_IGNORED_BUILDS non-zero exit → misleading "pnpm failed": agreed; the profile's pnpm-workspace.yaml is generated at packages/boot/app-boot/src/profile.ts:138-143 (nodeLinker: hoisted, autoInstallPeers: false) — the plugin-add wrapper treating that specific code as a warning is a clean, small fix.
2. pnpm 11 skipping postinstall → ensure-spawn-helper.mjs never runs: this is the same node-pty native helper implicated in [Bug][Windows] dsh web 随机静默死亡：node-pty 1.2.0-beta.15 ConPTY socket 无 error 监听 + windowsTerminal 错误处理器 throw #4436 (the Windows ConPTY crash thread) — subprocess-local/scripts/ensure-spawn-helper.mjs restores the executable bit that npm strips from node-pty's prebuilt spawn-helper. If pnpm 11 skips it, the tree installs "successfully" and Windows shell spawn fails only at first use. The fix is to add onlyBuiltDependencies: ['node-pty'] to the generated pnpm-workspace.yaml (profile.ts:138-143), so the helper build is approved by default in every profile.

I have PR-ready blueprints for the publish.ts dist-tag sync, the baseline latest==newest gate, and the pnpm-workspace.yaml onlyBuiltDependencies entry — happy to draft them when the PR channel opens. In the meantime, your pinned--E workaround is the right user-side mitigation.