插件批量更新加速 basaltfold/dsh-plugin-fast

dsh-plugin-fast

让 DSH 的插件市场点一下就能全部更新好，而不是一个插件等几分钟到几十分钟。

这是一个命令行工具（不是能被插件市场加载的 DSH bundle，见文末「它不是什么」）。所有数字都在一台真实机器上跑出来，不是估算。

它解决什么

DSH 插件市场的「全部更新 (N)」是严格串行的：每更新一个插件就单独起一次 pnpm add，而每一次都会重新验证并重放整份 lockfile（实测 473 条条目）。N 个插件 = N 次全树重放。

三个原因叠加，让它从「几十秒」变成「几个小时」：

| 现象 | 真实原因 |
| 点更新必然失败 | pnpm 11 的 minimumReleaseAge 默认 1440 分钟（24 小时），而且它做的是整份 lockfile 校验 —— 只要已装依赖里有一个版本是 24 小时内发布的，这个 profile 的所有安装/更新都会被拒（ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION） |
| 更新不动 / 卡很久 | git 全局配置里的代理端口关了，而所有 github: 依赖都走 git，且 git 只读全局 http.proxy，不读环境变量 |
| 慢 | 下载区域镜像的 tarball 延迟差 10 倍（实测 2697ms vs 283ms）；github: 悬浮规格每次都要去问 GitHub HEAD（实测 10.7 秒/次） |

其中第一条在官方桌面宿主上无解：市场被明确禁止传 --config.minimum-release-age=0（acceptsMarketPnpmFlags: false），所以只能从 profile 自己的 pnpm-workspace.yaml 解决 —— 这正是 fix-profile.mjs 做的事。

实测数字

同一台机器、同一个镜像、都是成功路径：

| 方式 | 16 个插件耗时 |
| 16 次独立 pnpm add（= 市场「全部更新」的行为） | 57 秒 |
| 一条 pnpm add a@x b@y … 装完 16 个 | 3.6 秒 |

单插件 pnpm add（热缓存）本身只要 4~5 秒 —— 所以「一个插件要几十分钟」从来不是 pnpm 的安装速度问题。

等待期那条的决定性验证（同一份真实 lockfile，只差一个键）：

不加键（= 默认状态） ✗ Lockfile failed supply-chain policy check (473 entries in 7.3s) [ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION] 7 lockfile entries failed verification

只加一行 minimumReleaseAge: 0 ✓ Lockfile passes supply-chain policies (473 entries in 10ms)

完整证据链、代码定位（routes.js:4671、official-desktop.js:562 等）见 docs/诊断与优化报告.md。

用法

1. 先修配置（默认预览，零写入）

node fix-profile.mjs

确认之后落盘（会先把被改的文件备份到 profile 里的 .fix-backup-<时间戳>/）：

node fix-profile.mjs --apply

它做四件事：

| # | 改动 | 为什么 |
| 1 | pnpm-workspace.yaml 写入 minimumReleaseAge: 0 | 解开「整份 lockfile 被拒」，这是更新失败的头号原因 |
| 2 | .npmrc 写入 npmmirror + 并发/重试/超时 + prefer-offline | 镜像快约 10 倍；网络抖动不再拖成整轮失败 |
| 3 | 探测 git 全局代理端口，连不上就移除 http.proxy / https.proxy | git 类插件失败的根因；代理还活着则保留不动 |
| 4 | 把悬浮的 github:owner/repo 固定到 lockfile 里已在用的那个 commit | 省掉每次安装的 GitHub HEAD 往返 |

可选：--release-age 60 保留 60 分钟等待期（保留一部分供应链保护，代价是刚发布的版本仍装不了）；--region global 让市场自己发起的安装也走 .npmrc 的镜像（见下）。

关于第 2 条的生效范围：市场在 region=china 时会向子进程注入 npm_config_registry，环境变量优先级高于 .npmrc，所以不改区域的话这一步对市场发起的安装无效。--region global 会写 .dsh-market/state.json 固定区域（代价：失去 gh-proxy.com 的 GitHub 兜底）。fast-update.mjs 是显式传 --registry，不受这条影响。

2. 批量更新

node fast-update.mjs --dry-run # 先看有哪些可更新
node fast-update.mjs # 一条 pnpm 命令装完全部

常用参数：--only a,b、--registry <url>、--profile <目录>、--pnpm <宿主自带 pnpm.cjs 路径>、--include-git。

行为要点：

- 并行查 registry 最新版本，用 semver 比较（区分精确版本与 range，正确处理 prerelease）
- 一次 pnpm add 装上全部目标 —— 这是 3.6 秒 vs 57 秒的来源
- 自动备份 package.json / pnpm-lock.yaml / pnpm-workspace.yaml；失败且版本没落地就自动还原
- pnpm 11 会把「有构建脚本未批准」当 exit 1（ERR_PNPM_IGNORED_BUILDS），这是良性告警 —— 脚本会先核对版本是否真的写进去了，再决定是否回滚

更新前请完全退出 DSH。 运行中的宿主会占用依赖文件，市场本身也有「agent 运行时拒绝替换文件」的保护（routes.js:4338）。退出后跑，就不会撞上它。

它不是什么

- 不是能被插件市场加载的 DSH bundle。 它没有 dsh.bundle.patch，装进配置档不会引入任何运行时代码 —— 这是刻意为之：一个写错的 cordis 补丁会破坏别人的 DSH 启动。它就是一个 npm 包形态的命令行工具（dsh-fast-update / dsh-fix-profile 两个 bin）。
- 不改插件本身。 它只动配置档的包管理配置与 git 配置，且全部先备份。
- 不能更新 DSH 桌面端自身（宿主限制，市场条目 #900）。

已知取舍

- minimumReleaseAge: 0 等于放弃「新版本冷静期」这层供应链保护，换来「一点就成功」。想两者兼顾用 --release-age 60。
- git 类依赖需要 git 本身能连上 GitHub；本工具不代理、不改 hosts。

License

MIT