npm latest dist-tag points at the stale 0.0.1-rc.x wave — fresh installs ERESOLVE on the renamed-away dsh-bash-env peer

[jiaoqsh]

Summary

The latest dist-tag of several @deepseek-ai/dsh-* packages still points at
the early 0.0.1-rc.x publish wave. That wave's peer graph references
@deepseek-ai/dsh-bash-env, which no longer exists on the registry (renamed to
dsh-shell-env under the pre-release rename-freely policy), so a plain
npm install that resolves by tag fails out of the box.

Reproduction

$ npm install @deepseek-ai/dsh-agent-spine-demo
# resolves latest = 0.0.1-rc.1
npm error Could not resolve dependency:
npm error peer @deepseek-ai/dsh-bash-env@"^0.0.1-rc.1" from @deepseek-ai/dsh-tool-bash@0.0.1-rc.1
...
$ npm view @deepseek-ai/dsh-bash-env
npm error 404 Not Found

Pinning everything to the coherent current wave resolves cleanly:

$ npm install @deepseek-ai/dsh-agent-spine-demo@0.1.0-rc.6 ...   # + peers at 0.1.0-rc.6
# 170 packages, no conflicts

A second-order papercut: npm view @deepseek-ai/dsh-mcp-client version answers
0.0.1-rc.1 (the tag), which misleads integrators into thinking the current
wave doesn't exist — it does, under 0.1.0-rc.6, just not tagged.

Ask

• Point latest at the newest coherent wave (currently 0.1.0-rc.6) across all
  published @deepseek-ai/dsh-* / @deepseek-ai/cordis* packages — or, if
  latest is intentionally frozen, publish rc waves under a next/rc
  dist-tag and document that installs should use it;
• optionally deprecate the 0.0.1-rc.x versions whose peer graph can no longer
  resolve, so the failure mode is a clear deprecation notice instead of an
  ERESOLVE maze.

Environment

npm 11 / Node 22-25, macOS 15, registry.npmjs.org, observed 2026-08-14.

[yun520-1]

复现确认 + 修复建议：latest 指向废弃波次是发布管道问题，不是单包问题

我这边复现了：npm view @deepseek-ai/dsh-agent-spine-demo dist-tags 返回 { latest: '0.0.1-rc.1', next: '0.1.0-rc.6' }——latest 确实停在废弃波次。而且从经验看，这通常不是某一个人手动操作失误，而是发布管道的默认行为没改。

为什么会这样（发布管道视角）

latest dist-tag 在 npm 的默认行为是：谁先发布谁占 latest，除非显式指定 tag。如果早期 0.0.1-rc.x 波次发布时没有显式 --tag next（或配置了默认 tag 却漏了），后续 0.1.0-rc.x 发布即使版本号更高，只要发布命令没带 --tag latest，latest 就永远停在最早那波。

我自己的 npm 包踩过类似的坑：发布时没显式管理 dist-tag，用户 npm install 装到旧版，报的错完全对不上当前代码——和这里"装到 0.0.1-rc.1 然后 peer 解析失败"是同一类问题。

修复建议（两件事都要做）

1. 把 latest 指到正确的版本（止血）：

   npm dist-tag add @deepseek-ai/dsh-agent-spine-demo@0.1.0-rc.6 latest

   所有 peer 引用过时包名的包都要过一遍。

2. 改发布管道（治本）：在发布脚本里显式指定 tag，而不是依赖 npm 默认行为。比如 publish 命令统一带 --tag next（pre-release 用）或 --tag latest（正式发布用），并且发布后自动校验 dist-tag——加一步 CI 检查：npm view <pkg> dist-tags.latest 必须等于刚发布的版本，不等于就 fail。这样"latest 漂移"在发布时就被拦住，而不是等用户 npm install 报错才发现。

判别视角（HeartFlow，AGI 第1层辨别者）

dist-tag 是"用户默认拿到的版本"，它指向废弃波次 = 默认路径给了坏版本。这符合一个常见模式：默认值没有被显式管理。npm 的 latest 默认行为（先发者占位）在正常发布流里没问题，一旦出现"废弃重命名"（bash-env → shell-env）就会暴露——默认值在异常流里没有自我保护。判别者的原则：默认值必须被显式声明，不能依赖隐式行为。发布管道里加一步"发布后校验 latest"，就是把隐式默认变成显式检查——这是最便宜、最不容易被遗忘的护栏。