Bug: 安装插件时 npm 删除 dsh 核心包导致 dsh web 启动失败

[Beihaisir]

Bug 反馈

概述

通过 dsh 安装第三方插件时（如 dsh-cost-meter、dshmarket、dsh-plugin-image-input、dsh-file-drop），npm 会在 dsh 自身的 node_modules 目录内执行 npm install --legacy-peer-deps。此过程中，npm 会删除那些未在 package.json dependencies 中显式声明、但运行时作为 bundled/peer 包必需的核心 @deepseek-ai/dsh-* 包。

这会导致 dsh web 启动失败，报 ERR_MODULE_NOT_FOUND。

环境信息

• 操作系统：Windows 11 (10.0.26200)
• Node.js：v24.19.0
• npm：11.17.0
• dsh：@deepseek-ai/dsh@0.1.0-rc.7（全局安装）

复现步骤

1. 全局安装 dsh：npm install -g @deepseek-ai/dsh@latest
2. 启动 dsh：dsh web → 正常运行
3. 从 dsh 插件市场安装插件（如 dsh-cost-meter、dshmarket、dsh-plugin-image-input、dsh-file-drop）
4. 再次执行 dsh web → 崩溃，报 ERR_MODULE_NOT_FOUND

错误信息

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@deepseek-ai/cordis-plugin-group' imported from
C:\Users\Administrator\AppData\Roaming\npm\node_modules@deepseek-ai\dsh\node_modules@deepseek-ai\dsh-app-boot\lib\index.js
code: 'ERR_MODULE_NOT_FOUND'

根因分析

从 npm 调试日志可以看到，插件安装过程中 npm 会修剪它认为"多余"的包：

731 silly REMOVE node_modules/@deepseek-ai/dsh-workflow
732 silly REMOVE node_modules/@deepseek-ai/dsh-timeout
733 silly REMOVE node_modules/@deepseek-ai/dsh-subprocess
...
742 silly REMOVE node_modules/@deepseek-ai/dsh-invariants
743 silly REMOVE node_modules/@deepseek-ai/dsh-fs
...
749 silly REMOVE node_modules/@deepseek-ai/cordis-plugin-group

这些包是由 dsh 的启动系统（dsh-app-boot）作为 bundled/peer 依赖注入的，但未在 package.json 的 dependencies 中声明。npm 的依赖修剪机制将它们视为多余包并删除。

期望行为

安装插件不应删除 dsh 核心包。建议修复方案：

1. 为插件使用独立的 node_modules 目录（如 ~/.dsh/plugins/node_modules），或
2. 在 package.json 的 dependencies 中固定所有必需的 @deepseek-ai/dsh-* 和 @deepseek-ai/cordis-* 包，防止被修剪，或
3. 安装插件时使用 npm install --no-prune 阻止删除已有包。

临时解决方案

安装插件后，重新执行：npm install -g @deepseek-ai/dsh@latest
可恢复被删除的包，但每次安装插件后都需重复此操作。

补充信息

• dsh 触发的 npm 安装命令：npm install --legacy-peer-deps dsh-cost-meter dshmarket @opendsh/dsh-plugin-setting-mcp dsh-plugin-image-input dsh-file-drop
• 工作目录：AppData\Roaming\npm\node_modules@deepseek-ai\dsh
• 共 19 个核心包被删除，导致 dsh 完全无法启动
• 测试环境：dsh 0.1.0-rc.7、npm 11.17.0、Node.js v24.19.0、Windows 11

[zoahdev]

核验了一点（对照 main/master HEAD 99f6f02 rc.7），先厘清安装路径再谈修复：

内置 dsh plugin 命令走的是 pnpm，不是 npm。 apps/cli/src/plugin.ts:3-5 明确是 "thin pnpm forwarder"——在 profile 目录里跑 pnpm <args>（plugin.ts:115-129），不会在 dsh 全局包的 node_modules 里执行 npm。你日志里的 npm install --legacy-peer-deps + 工作目录 AppData\Roaming\npm\node_modules\@deepseek-ai\dsh 说明这个安装来自别的入口：很可能是某个插件市场/商店的"一键安装"脚本（dsh-hub.cc？dsh-subscribe？还是手动在全局包目录里跑的 npm？）。方便的话确认一下触发面，这决定修哪边。

机制本身确认：npm 11 会修剪 package.json 未声明的包；dsh-app-boot 的 bundled/peer 注入依赖（cordis-plugin-group、dsh-workflow、dsh-invariants、dsh-fs、dsh-subprocess…）不在 dsh 主包 dependencies 里声明，所以在 dsh 全局包目录执行任何 npm install 都会被 prune 掉 → ERR_MODULE_NOT_FOUND。你的 npm 日志 REMOVE 行就是证据。

修复建议排序：

1. 插件独立 node_modules（~/.dsh/plugins/…）——正解：与"out-of-tree 插件不污染宿主"原则一致（Remote contribution registry for out-of-tree Host plugins #3167/[Proposal] Session event registration for out-of-tree plugins — unknown event types refuse resume (dsh-click/observed|action crashes rc.6/rc.7) #3191 同族），从根上消除修剪风险；
2. 主包声明全部 bundled/peer 依赖——脆弱：每次 release train 都要同步，且 npm 仍可能修剪"看起来多余"的传递依赖；
3. --no-prune——掩盖问题：其他安装仍会触发，且让包目录状态不可复现。

临时逃生：重装 dsh（你已验证有效），或改用 dsh plugin --profile web add <pkg>（走 pnpm profile 路径，不碰全局包目录）。

这个值得单独开 issue 修（商店安装脚本 + 宿主隔离两个层面）。需要的话我可以把"插件独立目录"的设计按 #3167 的 capability registry 思路细化。

[Beihaisir]

感谢详细排查，已确认触发面。

查证结果

正常流程没有问题

确认 dsh plugin 是 thin pnpm forwarder，在 profile 目录（~/.dsh/profiles/web/）里跑 pnpm，不会碰全局包目录。dshmarket 的 runDshPlugin 也是调用 dsh plugin --profile web add ...，走 pnpm 路径，cwd 应该是 profile 目录。

问题出在 cwd

但从 npm 调试日志确认，那次出事的安装命令 cwd 是：

C:\Users\Administrator\AppData\Roaming\npm\node_modules\@deepseek-ai\dsh

这是 dsh 全局包目录，不是 profile 目录。执行的命令是：

npm install --legacy-peer-deps dsh-cost-meter dshmarket @opendsh/dsh-plugin-setting-mcp dsh-plugin-image-input dsh-file-drop

这说明安装不是通过 dsh plugin 或 dshmarket 的正常 pnpm 流程触发的，而是某个入口在 dsh 全局包目录里直接跑了 npm install。

可能的触发源

排查了 dshmarket 的 dsh-cli.js，其 runDshPlugin 走的是 dsh plugin --profile <p> add ... → pnpm，cwd 来自 dshArgv()，正常情况下不会落到全局包目录。但 dshArgv() 在通过 dsh 命令启动时返回 cwd: undefined（继承父进程 cwd），如果父进程的 cwd 恰好是全局包目录，就会出事。

最可能的场景：在 dsh 全局包目录下手动执行了 npm install 安装插件，npm 修剪了未在 dependencies 中声明的 bundled/peer 包。

结论

两个层面都有问题：

1. 用户侧：不应在 dsh 全局包目录里直接跑 npm install，应该用 dsh plugin --profile web add <pkg>（走 pnpm profile 路径）
2. 框架侧：dsh-app-boot 的 bundled/peer 依赖未声明在 package.json dependencies 中，在任何 npm install 触发时都会被修剪。即使正常流程走 pnpm，用户误操作或第三方脚本仍可能在该目录触发 npm install

支持"插件独立 node_modules"的方案，从根源消除修剪风险。在修复落地前，我改用 dsh plugin --profile web add <pkg> 来安装插件。