[BUG] 插件管理器裸包名安装受 pnpm 11 minimumReleaseAge 默认值影响：新版本发布 24 小时内静默降级到上一版并被判不兼容

[pulsar-catnya]

桌面端插件管理器：裸包名安装会被 pnpm 11 的 24 小时发布时长隔离静默降级到旧版本，随后被兼容性检查拒绝

---

环境

项	值
客户端	官方桌面客户端（Electron），app.asar 版本文件 44.0.0
DSH 运行时	0.2.0-rc.2（@deepseek-ai/dsh-base / dsh-tools / dsh-web-app / dsh-app-boot 均为该版本）
profile	desktop（%USERPROFILE%\.dsh\profiles\desktop）
插件管理器自带的 pnpm	11.7.0（profile 内 .modules.yaml 的 packageManager）
注册源	客户端探测后选中 registry.npmmirror.com（registry.npmjs.org 的 dist-tags 完全相同）
操作系统	Windows x64
被安装的插件	dsh-drawai（标准 DSH bundle 插件，dsh.bundle.patch）
时间	均为北京时间（UTC+8），2026-10-08

摘要

在「插件 → 添加插件」中用裸包名（不带版本号）安装插件时，如果该插件的最新版本发布时间不足 24 小时，插件管理器会解析到一个更旧的版本；而该旧版本往往已经不兼容当前 DSH 运行时，于是安装被"兼容性检查"拒绝并整体回滚。

dsh-drawai 就是一个确定性复现的例子：包名裸装 → 解析到 0.1.1 → 报"不兼容 dsh 0.2.0-rc.2"→ 回滚。而实际上 0.2.1 完全兼容，只是"太新"被隔离策略挡住了。

根因是 pnpm 11 的供应链默认设置 minimumReleaseAge = 1440 分钟（24 小时），不是 DSH 自己的配置——但在当前安装流程里，这个降级既没有被告知，也不会被兼容性约束纠正，最终以一条误导性的错误信息呈现给用户。

复现步骤

1. 桌面客户端（DSH 0.2.0-rc.2），确保目标插件最新版本发布于 24 小时以内。
2. 打开侧栏 插件 → 添加插件。
3. 输入裸包名（不带版本号），例如 dsh-drawai，回车 / 点「安装」。
4. 观察：pnpm 解析并安装的是 24 小时内最新那个版本的上一版，随后 DSH 报不兼容并回滚。

本例三次操作的实际结果：

#	时间	输入	pnpm 结果	DSH 结果
1	22:12:43	dsh-drawai	+ dsh-drawai ^0.1.1	拒绝 + 回滚
2	22:22:45	dsh-drawai	+ dsh-drawai ^0.1.1	拒绝 + 回滚
3	22:30:49	dsh-drawai@0.2.1	+ dsh-drawai 0.2.1	成功（并写入了隔离豁免）

预期行为 / 实际行为

预期：安装可用的最新版本；若最新版本因某种原因不可用，明确说明原因，并且不要解析到一个与当前运行时已知不兼容的版本。

实际：

• 静默降级到旧版本；
• 用一条"不兼容"的错误把用户引向一个错误的补救动作（见下）；
• 没有任何地方提到"最新版本存在、只是被发布时长隔离挡住"。

关键证据

1) 版本与发布时间（registry.npmjs.org / npmmirror 一致）

0.1.0  2026-09-16T15:23:20Z
0.1.1  2026-09-20T08:29:56Z   ← 被解析到的版本
0.2.0  2026-10-07T14:28:39Z   ← 首次尝试时 23h44m 大，差 16 分钟不满 24h
0.2.1  2026-10-08T13:50:31Z   ← 最新版，发布仅 22 分钟；peer 范围兼容 0.2.x

两源的 /latest 端点当时与事后都返回 0.2.1。元数据本身没有问题。

2) 兼容性（peerDependencies["@deepseek-ai/dsh-tools"]）

0.1.1 : >=0.1.0-rc.1 <0.1.0 || >=0.1.5-rc.1 <0.2.0-0
        → 不含 0.2.x，与 dsh 0.2.0-rc.2 不兼容（DSH 的判断正确）

0.2.0 : ... || >=0.2.0-rc.1 <0.3.0-0
0.2.1 : ... || >=0.2.0-rc.1 <0.3.0-0
        → 命中 0.2.0-rc.2，兼容

3) 插件管理器日志（原文）

第一次尝试（失败）：

✓ Lockfile passes supply-chain policies (verified 14m ago)
Progress: resolved 1, reused 0, downloaded 0, added 0
[WARN] Issues with peer dependencies found. Run "pnpm peers check" to list them.

dependencies:
+ dsh-drawai ^0.1.1

Packages: -27
Progress: resolved 54, reused 0, downloaded 0, added 0, done
Done in 940ms using pnpm v11.7.0

dsh: installation rejected: Plugin dsh-drawai@0.1.1 is incompatible with dsh 0.2.0-rc.2:
peerDependencies {"@deepseek-ai/dsh-tools":">=0.1.0-rc.1 <0.1.0 || >=0.1.5-rc.1 <0.2.0-0"}.
Running it may cause crashes or data loss. Update the plugin or install a plugin version compatible
with this dsh runtime. To accept this risk explicitly, grant the exact-version exemption for
dsh-drawai@0.1.1 on dsh 0.2.0-rc.2 with `dsh plugin allow-version` or the plugin manager, then retry
the installation or restart dsh. Exact-version exemption: not active.
dsh: restored package.json, pnpm-lock.yaml, and node_modules.

第三次尝试（指定版本，成功）—— 日志里藏着根因：

dependencies:
+ dsh-drawai 0.2.1

Packages: +1 -27
...
Added 1 entry to minimumReleaseAgeExclude in pnpm-workspace.yaml
(set minimumReleaseAgeStrict to true to gate these updates with a prompt):
  dsh-drawai@0.2.1
Done in 11.2s using pnpm v11.7.0

minimumReleaseAgeExclude 这个提示是 pnpm 自己打印的，说明当时确实有发布时长隔离在生效。安装后 profile 的 pnpm-workspace.yaml 被追加：

minimumReleaseAgeExclude:
  - dsh-drawai@0.2.1

4) 对照实验（决定性）

在一个全新的空项目里用全局 pnpm 11.21.0、npmmirror 源、全新 store/cache 执行裸包名安装：

$ pnpm add dsh-drawai
dependencies:
+ dsh-drawai 0.2.0

执行时间约 22:35，此时 0.2.1 只有 45 分钟大、0.2.0 已 24 小时 07 分。安装的是 0.2.0 而不是最新的 0.2.1 —— 证明隔离策略与 DSH 无关，任何 pnpm 11 环境都会这样解析。

该实验同时把阈值夹定在 (23h54m, 24h07m]，与官方文档的 1440 分钟完全吻合。

5) 官方文档（根因确认）

pnpm 官方《缓解供应链攻击》：

来源：https://pnpm.io/zh/supply-chain-security

（pnpm 11 的"延迟依赖更新"是有意为之的安全特性，不是 bug。问题在于它与插件安装流程的交互。）

根因

用户输入裸包名
   ↓
插件管理器把 spec 交给 profile 内的 pnpm 11.7.0
   ↓
pnpm 11 默认 minimumReleaseAge = 1440（24h）
   → 过滤掉"发布不足 24 小时"的版本，解析"够旧的最新版"
   ↓
若最新版是刚发布的，解析结果 = 上一版（本例 0.1.1）
   ↓
DSH 兼容性校验（正确）判定它不兼容当前运行时
   ↓
安装被拒绝 + 整体回滚

时间窗口： 一个插件每发布一个新版本，接下来的 24 小时内，裸包名安装都会解析到上一版。对于像 dsh-drawai 这样每个版本都会调整 peerDependencies 范围的插件，上一版往往正好不兼容 —— 于是这 24 小时内该插件无法用裸包名安装，任何用户都会撞上一条吓人的"可能崩溃/丢数据"提示。

本例的具体窗口：0.2.0 发布于 10-07 22:28，直到 10-08 22:28 才满 24 小时；在此之前裸装一律解析到 0.1.1 并被拒绝。这也解释了为什么 22:12 和 22:22 两次尝试必然失败（只差 16 分钟和 6 分钟），而 22:30 指定版本后立即成功。

影响与危害

1. 新发布的插件 24 小时内无法按包名安装。
2. 错误信息误导用户做出危险动作。 提示虽然写了"更新插件或安装兼容版本"，但同时提供了「为 dsh-drawai@0.1.1 授予精确版本豁免」——而 0.1.1 是因为隔离策略才被选中的降级产物，本身确实不兼容。用户照着做等于主动接受崩溃/数据损坏风险，而这个风险完全是流程造成的假象。这是本报告最重要的一点。
3. 降级是静默的。 出错前没有任何地方显示"你要求的包有更新的版本，但它发布不足 24 小时"。
4. 副作用未被告知。 一旦用带版本号的 spec 装成功，pnpm 会把该版本永久写进 profile 的 pnpm-workspace.yaml（minimumReleaseAgeExclude），等于对该包静默削弱了这道安全防线。用户不知道自己的安全设置被改动了；在 minimumReleaseAgeStrict 未开启时不会有任何确认。

建议修复（按优先级）

1. 版本选择要同时满足"发布时长"与"运行时兼容"两个约束。
   解析候选版本时，若最新版被发布时长隔离挡住，应继续向下找一个与当前 DSH 运行时兼容的版本；找不到就明确报"最新兼容版本 X 因发布不足 24 小时暂不可安装"，而不是塞一个已知不兼容的版本进去。

2. 重写这条错误信息。 当被拒绝的版本是隔离策略造成的降级产物时，应当：

   • 明说"本次解析到 0.1.1 是因为 0.2.1 发布不足 24 小时"；
   • 直接给出最新兼容版本（0.2.1）及可一键执行的安装方式（包名@0.2.1）；
   • 给出该版本可被自动解析的时间点 / 或提供"稍后重试"；
   • 不要在这种情况下建议"授予版本豁免"。

3. 不要在用户无感的情况下改动供应链设置。 安装流程若需要写 minimumReleaseAgeExclude，应当在安装结果里明确列出，或默认开启 minimumReleaseAgeStrict 让用户确认。

4. 把 minimumReleaseAge 纳入插件安装策略的一部分。 建议为插件安装显式声明策略（例如安装页面显示"新版本发布满 24 小时后可自动获取"），让行为可预期而不是隐式继承 pnpm 默认值。

已验证的绕过方式

方式	结果
输入带版本号的 spec：dsh-drawai@0.2.1	✅ 成功。pnpm 自动把该版本加入 minimumReleaseAgeExclude 并安装；由于 0.2.1 本身兼容，兼容性校验通过
等最新兼容版本发布满 24 小时后再用裸包名	✅ 会成功（本例 10-08 22:28 之后裸装解析到 0.2.0 即可通过校验）
github:owner/repo 形式	⚠️ 未实测；理论上绕开注册源发布时间元数据（minimumReleaseAge 只作用于注册源版本）

附：其他观察（非阻塞）

• 每次安装 pnpm 都会先 Packages: -27 再重建，失败时由 DSH 整体还原 node_modules。还原是正确的（事后核对：profile 内应有的 26 个包一个不缺），但一次失败尝试要动 27 个包的链接，代价偏大。
• 该插件（dsh-drawai）本身没有问题：包完整（cordis.patch.yml + 预构建 lib/）、无安装期脚本、peerDependencies 声明正确，最新版与 0.2.0-rc.2 兼容。本报告针对的是安装流程，不是插件。

---

报告整理者：DSH 会话内 AI 助手；证据来自本机 %USERPROFILE%\.dsh\profiles\desktop\.plugin-manager\logs\、pnpm 元数据缓存、注册源响应与一次对照实验，另引用了 pnpm 官方文档。

[PerryLink]

机制、时间线、peer 范围我都核过了，你的判断基本全对，而且我用 pnpm 实测复现了你缺的那一环。补一处更准的根因表述，再指出一个可直接提的上游改进点。

1. 我实测复现了关键分歧：pnpm view 不吃门限，pnpm add 吃

本轮实测（默认门限、registry.npmjs.org）：

pnpm view dsh-drawai version   → 0.2.6
pnpm add  dsh-drawai           → + dsh-drawai 0.2.4

当时 0.2.6 发布仅 3.9 h、0.2.5 仅 5.1 h、0.2.4 已 44.9 h。

⇒ pnpm view 不受 minimumReleaseAge 约束，pnpm add 受。 而 DSH 的检查与预检用的正是 pnpm view：packages/boot/plugin-manager/src/operations.ts:177-184 跑的是 'view', parsed.spec, 'name', 'version', 'peerDependencies', '--json'。

所以比"静默降级"更准确的根因是：

检查与安装用了两把不同的尺子。 预检读到的是最新版（peer 范围兼容），安装却拿到被门限压下来的旧版（peer 范围不兼容），于是走到"不兼容"这条错话术。

这个表述比"解析到旧版本"更能解释你观察到的三件事：预览显示 0.2.1 → 装出来 0.1.1 → 最后报不兼容。建议把标题的「静默降级」改成「检查与安装的门限不一致」。

2. 你贴的日志来自"装后检查"，不是预检

operations.ts 里两种拒绝文案是分开的：

• 预检拒绝 → :351 是 'nothing was installed'
• 装后校验拒绝 → :515 是 'restored package.json, pnpm-lock.yaml, and node_modules'

你日志末行是后者 ⇒ 预检放行了（因为 view 读到的是兼容的新版本），pnpm 装完 0.1.1 才被 :465-524 的装后校验拒绝。顺带排除一个可能：dsh-v0.2.0-rc.2 上预检已经存在（git grep namedSpecManifest dsh-v0.2.0-rc.2 → operations.ts:167/342/351），所以不是"旧版没有预检"。

3. 仓库对 minimumReleaseAge 是有认知的 —— 但说明只挂在成功路径上

已经写了这个机制的地方不少：

• packages/boot/plugin-manager/src/types.ts:136 → /** The installed bundle's manifest version, when declared; pnpm's minimumReleaseAge can make it older than the newest release. */
• packages/boot/plugin-manager/README.md:60 同义
• apps/desktop/README.md:273 记录了豁免会写进 profile 的 pnpm-workspace.yaml
• UI 里甚至已经有现成文案：packages/client/ui-plugin-manager/src/client/locales.ts:187（zh）/ :403（en）的 installDoneOtherVersion，内容就是"根据 pnpm 供应链安全策略（minimumReleaseAge）…本次安装的是 {installed}，而非最新版本 {version}…"

但它只在成功路径渲染：packages/client/ui-plugin-manager/src/client/PluginManagerPage.tsx:1290-1301 的条件以 phase === 'done' 开头；失败态走 :853-859（failure.code === 'incompatible-version' → managementText(...)），全程不提门限。

⇒ 这就是最值得提的那条改进：incompatible-version 的拒绝路径（由 packages/boot/plugin-manager/src/index.ts:546 抛出）应当补上"读到的版本 vs 装到的版本"的比较，并复用已有的 installDoneOtherVersion 文案。这样失败提示会自动指出"最新版存在，只是被发布时长隔离"，而不是把用户推向 allow-version。

你第 4 点（minimumReleaseAgeExclude 被静默写入 pnpm-workspace.yaml）成立，但要收窄：只有显式指定版本（如 dsh-drawai@0.2.1）时 pnpm 才会为绕过门限登记豁免；裸包名降级那次不会写（本轮实测复现：裸装 0.2.4 后 pnpm-workspace.yaml 未被改动）。另外 profile 的 pnpm-workspace.yaml 本身不被安装流程还原（index.ts:565 注释 + RESTORED_FILES = ['package.json','pnpm-lock.yaml']，index.ts:81），所以豁免会长期留在 profile 里。

4. 没有任何 DSH 级旋钮

• packages/boot/plugin-manager/src/index.ts:42-63 的 Config 只有 pnpmCommand / outputBytes / lockWaitMs / inspectTimeoutMs / githubConnectionTimeoutMs / idleTimeoutMs / registry / fallbackRegistries —— 没有 minimumReleaseAge
• profile 模板 packages/boot/app-boot/src/profile.ts:247-252 生成的是 packages:\n - .\n\nnodeLinker: hoisted\nautoInstallPeers: false，不含该项 ⇒ 继承 pnpm 默认 1440 分钟

⇒ 所以"DSH 既不覆盖也不提供配置"这句可以直接写进报告。

5. 正确处置（你这条判断对，我同意）

显式指定版本：dsh plugin add <name>@<compatible-version>（pnpm 会自行登记 minimumReleaseAgeExclude），或等满 24 小时，或在 profile 的 pnpm-workspace.yaml 里自行放宽。

不要照"不兼容"提示去 allow-version 一个只是因为门限才被选中的版本 —— 这一点你说得对，而且上面第 3 节正是它发生的原因。

6. 版本

你写 0.2.0-rc.2。我核的是 origin/master = d743267388（= dsh-v0.2.1-alpha.2），上述配置面、文案位置与 PluginManagerPage.tsx 的成功态条件都没变 ⇒ 缺口在最新线上仍在。你自己那份时间线我只在你机器上无法复跑，但机制部分我端到端复现了。