通过 Mise 安装 npm:@deepseek-ai/dsh 时 Aube 无法解析互递归 peer dependencies

[sommio]

环境

• mise 2026.7.14（Linux x64）
• 安装命令：mise use -g npm:@deepseek-ai/dsh
• 解析版本：@deepseek-ai/dsh@0.1.0-rc.6

问题

Mise 默认通过 Aube 安装 npm 工具。解析 dsh 的依赖树时失败：

peer-context fixed-point did not converge after 16 iterations. mutually recursive peers, lockfile would be incomplete

此前还遇到两个 trust downgrade：

• @smithy/core@3.33.0
• @smithy/node-http-handler@4.11.0

对这两个精确版本配置 trust_policy_excludes 后，解析会继续，但最终仍在上述互递归 peer 依赖处失败。因此这不是单纯的信任策略问题。

影响

无法用 Mise 默认的安全安装路径安装 dsh。npm.shell_out=true 虽能改用 npm CLI，但会绕过 Aube 的 npm 供应链信任检查，不适合作为长期全局配置。

请问官方是否能：

1. 确认依赖树中的互递归 peer 关系是否预期；
2. 提供适合第三方解析器/包管理器的依赖调整方案，或官方推荐的 Mise 安装方式；
3. 说明上述 Smithy 发布可信度元数据变化是否符合预期。

可按需补充完整 verbose 日志和 lockfile/依赖树信息。

[PerryLink]

先给出可以确证的一半：你看到的互递归 peer 不是误报，公开元数据里确实有闭合的环。

在 @deepseek-ai/cordis@4.0.2（今天的 latest）上，环是二元且互相 pin 死的：

@deepseek-ai/cordis@4.0.2
  peer → @deepseek-ai/cordis-plugin-loader@^1.0.3
  peer → @deepseek-ai/cordis-plugin-include@^1.0.7

@deepseek-ai/cordis-plugin-loader@1.0.3
  peer → @deepseek-ai/cordis@^4.0.2          ← 指回 cordis，环闭合
  peer → node-addon-require-builtin@^0.1.4

@deepseek-ai/cordis-plugin-include@1.0.7
  peer → @deepseek-ai/cordis@^4.0.2
  peer → @deepseek-ai/cordis-plugin-loader@^1.0.3

4.0.2 要 loader ^1.0.3，loader 1.0.3 又要 cordis ^4.0.2 —— 两者只能成对收敛，单独先定哪一个都不合法。cordis-plugin-include 再加一条边，构成三元环。旧线同理：@deepseek-ai/cordis@4.0.1 的 peer 是 loader ^1.0.2 / include ^1.0.6。

你那条命令解析到的 @deepseek-ai/dsh@0.1.0-rc.6 正好落在旧线上：它的依赖里 @deepseek-ai/cordis 是 ^4.0.1、@deepseek-ai/cordis-plugin-loader 是 ^1.0.2，而这两个包的可用版本分别停在 4.0.2 和 1.0.3，所以解析时必然构成上面的环。所以第 1 问的答案是：这个环在当前发布元数据里是真实存在的结构，不是 Aube 的误判。

有一个命名陷阱值得单独排查，因为它会让「带环」变成「冲突」：

• npm 上确实存在无 scope 的 cordis，但它停在 4.0.0-rc.10（dist-tags.latest）；
• 而无 scope 的 cordis-plugin-loader 根本没有发布过（registry 404），它只以 @deepseek-ai/cordis-plugin-loader 存在。

也就是说 cordis 与 cordis-plugin-loader 在这个依赖图里属于不同的 scope 命名空间。如果解析器把裸 cordis 认成那个无 scope 的包，就会拿到 4.0.0-rc.10，与 loader 1.0.3 要求的 ^4.0.2 直接矛盾 —— 这种情况下无论迭代多少次都不会收敛，因为约束本身不可满足。

需要你补充才能继续往下判的部分

peer-context fixed-point did not converge after 16 iterations 这条报文的具体收敛语义与 16 次上限属于 Aube 的实现细节，我这边没有 mise、也没有 aube，无法复现，因此不能替你断定是环本身触发了它，还是 trust 策略让它提前退出。请补三样：

1. mise 与 aube 的确切版本（你给的是 mise 2026.7.14，aube 版本麻烦单独确认）；
2. mise use -g npm:@deepseek-ai/dsh 的完整 verbose 日志，特别是它在报错前最后解析的是哪几个包；
3. 失败时已生成的部分 lockfile / 依赖树。

第 2 点能直接区分上面两种情形：如果日志显示它已经同时定下了 cordis@4.0.2 与 loader@1.0.3 之后才开始来回迭代，那是环导致的；如果它在 cordis@4.0.0-rc.10 与 ^4.0.2 之间反复，那是命名空间问题。

关于第 2 问的可行路径

先说清前提：我没有在 mise 下验证过任何一条，以下是按机制给出的条件化选项，请你按自己的复现结果取舍。

• 改用更新的版本线。你说的 npm.shell_out=true 能绕过，但正如你自己指出的，那会跳过 Aube 的供应链信任检查，不适合作为长期全局配置 —— 这个顾虑是成立的，不建议把它当默认值。
• 成对固定版本。如果 Aube 支持传递性地钉版本，把 @deepseek-ai/cordis 与 @deepseek-ai/cordis-plugin-loader 作为一对同时固定（例如 4.0.2 + 1.0.3），可以消除「先定一个再定另一个」的迭代需求。这要求解析器允许对 peer 也施加 overrides，mise/aube 侧是否支持需你确认。
• 别把裸 cordis 当依赖。若日志显示它去取了无 scope 的 cordis，把它限定到 @deepseek-ai/cordis 就能消掉这一类不可满足约束。

第 3 问（@smithy/core@3.33.0 与 @smithy/node-http-handler@4.11.0 的发布可信度元数据变化是否符合预期）涉及第三方包的发布侧元数据，DSH 这边无法代答，需要由官方或该包维护者说明。

如果上面关于依赖图的结论对你有用，可以把它标为 answer，方便后面同样卡在互递归 peer 上的人找到。