[Bug] dsh 0.1.0-rc.8 is not installable from npm: missing dsh-agent-loop@^0.1.0-rc.8

[Metahumanz]

Environment

• Windows 11
• PowerShell 7.6.5
• Node.js v24.14.0
• npm 11.12.1

Reproduction

npx -y @deepseek-ai/dsh@0.1.0-rc.8 --version

The command stalls for a long time during npm's idealTree dependency resolution.

Running the same command with peer dependency resolution disabled exposes the underlying error:

npx -y --prefer-offline --timing --legacy-peer-deps @deepseek-ai/dsh@0.1.0-rc.8 --version

Result:

npm error code ETARGET
npm error notarget No matching version found for @deepseek-ai/dsh-agent-loop@^0.1.0-rc.8.
npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist.

As a control, rc.7 works normally in the same environment:

npx -y --prefer-offline --timing @deepseek-ai/dsh@0.1.0-rc.7 --version

Result:

0.1.0-rc.7

It looks like the rc.8 npm release may be missing @deepseek-ai/dsh-agent-loop@0.1.0-rc.8 or another package in the rc.8 release set.

[qing3a]

Thanks for the detailed report — reproduced and root-caused against the registry.

Verified facts:

• @deepseek-ai/dsh-agent-loop@0.1.0-rc.8 is published. npm view @deepseek-ai/dsh-agent-loop versions lists it, and a fresh --legacy-peer-deps install of @deepseek-ai/dsh@0.1.0-rc.8 resolves fine right now (486 packages, no ETARGET).
• dsh-agent-loop's latest dist-tag still points at 0.1.0-rc.6 (next is 0.1.0-rc.8).

Most likely cause of the ETARGET: stale npm cache from the publish-propagation window. rc.8 shipped 2026-08-19 ~15:37 UTC; if your npm cache fetched the dsh-agent-loop packument just before rc.8 propagated, --prefer-offline serves that stale metadata (which only lists up to rc.6/rc.7) → No matching version found for ^0.1.0-rc.8.

Unblock:

npm cache clean --force
npx -y @deepseek-ai/dsh@0.1.0-rc.8 --version

Drop --prefer-offline on the first run so fresh packuments are fetched.

Observation for maintainers (optional): since npx @deepseek-ai/dsh@0.1.0-rc.8 pins its sub-packages to ^0.1.0-rc.8, keeping the latest dist-tag in sync with each rc release would make cached/--prefer-offline flows much more forgiving in the future.

[denial123789]

Confirmed the package is currently visible on the official registry, including its tarball integrity. One operational refinement: preserve the configured-registry and cached-packument evidence before using a broad npm cache clean --force. A new, isolated cache is enough to prove the boundary without destroying shared state:

probe_cache="$(mktemp -d)"
npx -y --cache "$probe_cache" \
  --registry=https://registry.npmjs.org/ \
  @deepseek-ai/dsh@0.1.0-rc.8 --version

If that succeeds while the configured registry fails, the owner is the mirror/proxy replication path—not the published release. Also, latest = rc.6 and next = rc.8 are useful human-facing tag facts, but an explicit ^0.1.0-rc.8 dependency can resolve rc.8 regardless of latest when the packument is fresh.

Full registry/cache decision table, PowerShell probe, CI cache guidance, and coordinated-release gates: https://sandbaseai.github.io/deepseek-harness-handbook/npm-etarget-rc8.html

Canonical guide: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/npm-etarget-rc8.md

[zhengyuzi]

是不是用的镜像源，镜像源还没有更新到最新版本