Windows Desktop 打包后启动失败：ERR_MODULE_NOT_FOUND，疑似 Electron shell runtime dependencies 不完整

[xingchenyang]

环境说明

我是在 Windows 上本地构建 Desktop。

为了避免之前遇到的 Windows 长路径问题，当前仓库放在较短路径：

C:\dsh

当前版本：

dsh-v0.1.7-alpha.1

环境大致为：

Windows
Electron 44.0.0
electron-builder 26.15.3
pnpm 11.7.0

---

问题现象

Desktop 可以正常完成 build 和 installer 生成，但运行最终 packaged application 时启动失败。

最开始的错误是：

ERR_MODULE_NOT_FOUND:
Cannot find package '@deepseek-ai/dsh-deepseek-account'

报错发生在最终 packaged application：

resources\app.asar\lib\main.js

为了排除 installer 本身的问题，我也直接运行了：

apps\desktop\.desktop-build\targets\win-x64\unsigned-artifacts\win-unpacked\DeepSeek Harness.exe

结果同样报错，因此问题看起来发生在 Desktop shell packaging，而不是 NSIS 安装过程。

---

第一次检查：dsh-deepseek-account

检查 apps/desktop/package.json 后发现：

@deepseek-ai/dsh-deepseek-account

原本位于：

devDependencies

但 Desktop shell 中存在实际 runtime import，例如：

import { desktopClientHeaders } from '@deepseek-ai/dsh-deepseek-account'

最终 packaged app.asar 中也确认：

app.asar\node_modules\@deepseek-ai\dsh-deepseek-account\package.json

不存在。

因此我做了一个临时验证，将：

@deepseek-ai/dsh-deepseek-account

从：

devDependencies

移动到：

dependencies

重新打包后，原来的 dsh-deepseek-account 错误消失了。

不过应用随后继续报：

ERR_MODULE_NOT_FOUND:
Cannot find package '@deepseek-ai/cordis'

这让我怀疑问题可能不只是单个 package 分类错误，而是 Electron shell 的 production runtime dependency 集合并不完整。

---

进一步检查

当前 Desktop package 实际涉及两棵不同的 dependency tree。

一棵是 Electron shell：

app.asar/
  lib/main.js
  node_modules/

另一棵是自定义 dsh runtime：

app.asar/dsh/
  node_modules/

在当前 build 中可以观察到：

app.asar/dsh/node_modules/@deepseek-ai/cordis

存在。

但 Electron shell 使用的是：

app.asar/node_modules

Node module resolution 不会自动从：

app.asar/lib

跳到：

app.asar/dsh/node_modules

因此 dsh runtime 中已经存在的 package，并不能自动满足 Electron shell 自身的 runtime import。

---

@deepseek-ai/cordis 的依赖关系

进一步检查后发现：

@deepseek-ai/dsh-deepseek-account

声明了 mandatory peer dependencies，包括：

@deepseek-ai/cordis
@deepseek-ai/dsh-brand

同时 Desktop shell 自身还实际运行时使用：

@deepseek-ai/dsh-app-boot
@deepseek-ai/dsh-home-paths
@deepseek-ai/dsh-deepseek-account
@deepseek-ai/dsh-api-gateway

其中部分 package 原本位于：

devDependencies

另外 dsh-app-boot 也有多个 non-optional peer dependencies，例如：

@deepseek-ai/cordis
@deepseek-ai/cordis-plugin-group
@deepseek-ai/cordis-plugin-include
@deepseek-ai/cordis-plugin-loader
@deepseek-ai/dsh-launch-environment
@deepseek-ai/dsh-home-paths
@deepseek-ai/dsh-system-prompt

所以单独补一个缺失 package 可能会继续暴露下一个缺失 peer provider。

---

临时解决方法

为了验证是否确实是 Electron shell runtime dependency 不完整，我临时调整了：

apps/desktop/package.json

将这些实际运行时使用的 package 放入 dependencies：

@deepseek-ai/dsh-app-boot
@deepseek-ai/dsh-home-paths
@deepseek-ai/dsh-deepseek-account

并补充其当前需要的 mandatory peer providers：

@deepseek-ai/cordis
@deepseek-ai/cordis-plugin-group
@deepseek-ai/cordis-plugin-include
@deepseek-ai/cordis-plugin-loader
@deepseek-ai/dsh-brand
@deepseek-ai/dsh-launch-environment
@deepseek-ai/dsh-system-prompt

修改后的 dependencies 大致为：

{
  "electron-updater": "^6.8.9",
  "semver": "^7.8.5",
  "ws": "^8.21.0",

  "@deepseek-ai/dsh-api-gateway": "workspace:^",
  "@deepseek-ai/dsh-app-boot": "workspace:^",
  "@deepseek-ai/dsh-home-paths": "workspace:^",
  "@deepseek-ai/dsh-deepseek-account": "workspace:^",

  "@deepseek-ai/cordis": "workspace:^",
  "@deepseek-ai/cordis-plugin-group": "workspace:^",
  "@deepseek-ai/cordis-plugin-include": "workspace:^",
  "@deepseek-ai/cordis-plugin-loader": "workspace:^",

  "@deepseek-ai/dsh-brand": "workspace:^",
  "@deepseek-ai/dsh-launch-environment": "workspace:^",
  "@deepseek-ai/dsh-system-prompt": "workspace:^"
}

然后执行：

pnpm install

并重新运行 electron-builder。

为了缩短验证时间，我没有重新执行完整 runtime preparation，而是只重新组装 Desktop shell：

pnpm.cmd --dir apps/desktop exec electron-builder `
  --config electron-builder.config.mjs `
  --win `
  --x64 `
  --publish never `
  --dir

重新生成 win-unpacked 后，运行：

DeepSeek Harness.exe

可以正常启动。

---

当前观察

目前看来，这个问题可能与 Desktop Electron shell 的 production dependency closure 有关。

dsh runtime 本身有自己的 package preparation / dependency closure 逻辑，因此：

app.asar/dsh/node_modules

中的依赖比较完整。

但 Electron shell：

app.asar/node_modules

主要依赖 apps/desktop/package.json 的 production dependencies。

如果 shell runtime 实际 import 的 workspace package 位于 devDependencies，或者它依赖的 mandatory peer provider 没有进入 shell 的 production dependency tree，那么最终 packaged application 可能出现：

ERR_MODULE_NOT_FOUND

---

临时 workaround

目前我本地可以通过调整：

apps/desktop/package.json

中的 runtime dependencies 和 mandatory peer providers，使最终 packaged Desktop 正常启动。

这只是为了确认问题范围的本地 workaround。

至于更合适的正式修复方式，我不确定应该是：

- 调整 apps/desktop/package.json 中的依赖分类

还是：

- 为 Electron shell 增加更完整的 production dependency closure / peer provider projection

或者项目中已有其它预期的 packaging 机制。

这部分更适合由维护团队根据 Desktop packaging 的设计来判断。

[PerryLink]

你这条我能在源码里定位到一个具体的、可核对的不一致，但它不是"少打了一个包"这么简单 —— 这个仓里同时存在两个名字相近的包，所以先别急着改名字。

1. 两个包都存在

packages/credentials/deepseek-account/package.json           name: @deepseek-ai/dsh-deepseek-account            version 0.1.7-alpha.1
packages/credentials/deepseek-account-platform/package.json  name: @deepseek-ai/dsh-deepseek-account-platform   version 0.1.7-alpha.1

CLI 的组合表里，插件 id deepseek-account 映射到的是带 -platform 的那个：

apps/cli/composition.md:221   | `deepseek-account` | `@deepseek-ai/dsh-deepseek-account-platform` |

而 Desktop 侧引用的是不带 -platform 的那个 —— 这不是笔误，是十几个文件一致的引用：

apps/desktop/package.json:64          "@deepseek-ai/dsh-deepseek-account": "workspace:^",
apps/desktop-host/package.json:23     "@deepseek-ai/dsh-deepseek-account": "workspace:^",
apps/desktop/src/host-process.ts:5    import type { PlatformSession } from '@deepseek-ai/dsh-deepseek-account'
apps/desktop/src/platform-view.ts:5   import { mergePlatformCookies, ... } from '@deepseek-ai/dsh-deepseek-account'
apps/desktop/src/mandatory-update-policy.ts:4  import { desktopClientHeaders } from '@deepseek-ai/dsh-deepseek-account'
apps/desktop-host/src/index.ts:8      import type {} from '@deepseek-ai/dsh-deepseek-account'
（同一名字还出现在 `preload-welcome.ts`、`welcome-api.ts`、`welcome-window.ts`、`account-backend.ts`、`client/WelcomePage.tsx` 以及多个测试里）

tsconfig.base.json 也两个名字都映射，各指向各自的 src/index.ts。

2. 为什么"本地能构建、打包后起不来"

打包集不是照抄 node_modules：apps/desktop/scripts/prepare-package-set.ts 的作用是

:1     Select and copy the local npm tarball closures that supply Desktop dsh and its private Host.
:35-36 const REQUIRED_DEPENDENCY_SECTIONS = ['dependencies', 'peerDependencies']
:59    export function selectDesktopPackageClosure(...)
:134   if (host === undefined) throw new Error(`desktop package set: selected closure omits ${DESKTOP_HOST_PACKAGE}`)

也就是说：它只从你提供的 tarball 闭包里选，并且只检查 Host 这一个包是否缺失（:134）。本地能跑是因为 workspace 链接 + tsconfig 路径别名都在；打包后的运行时两样都没有，缺哪个包就是 ERR_MODULE_NOT_FOUND。所以：

• 报错说明 @deepseek-ai/dsh-deepseek-account 的 tarball 不在你打包时提供的输入目录里（或没被闭包走到）；
• 这只在 packaged 运行时暴露，与"build 成功、installer 生成成功"并不矛盾。

请补一个数据点来确定是哪一种：你打包时传给 --from 的那个 tarball 目录里，dsh-deepseek-account（不带 -platform）的 .tgz 在不在？在，就是闭包遍历的问题；不在，就是打 tarball 那一步漏了它。

3. 一处值得上游看的东西

prepare-package-set.ts:134 只为 Host 一个包做"缺了就报错"的检查，其他 workspace 依赖缺失是静默通过的 —— 于是失败被推迟到你截图里的启动时刻。这是我认为这条报告最有价值的部分：把"闭包里缺包"从运行期 ERR_MODULE_NOT_FOUND 变成打包期的明确报错。

边界：读的是 c36a83ff6b（dsh-v0.1.7-alpha.1）的提交树；我没有构建 Windows Desktop，也没有你的打包输入目录 —— 第 2 点里"tarball 不在输入里"是从 prepare-package-set.ts 的行为推出的待你确认的结论，不是实测。

[xingchenyang]

按照你的思路，我重新用原版 dsh-v0.1.7-alpha.1 做了一次干净构建，并检查了最终 ASAR 里的实际内容。

下面只记录这次检查到的结果。

构建状态

源码状态：

HEAD detached at dsh-v0.1.7-alpha.1
nothing to commit, working tree clean

重新执行完整 Windows Desktop unsigned build 后，Office runtime smoke 通过：

desktop runtime: DOCX, XLSX, PPTX to PDF passed

dsh-deepseek-account tarball

在下面两个目录中都可以找到：

apps\desktop\.desktop-build\targets\win-x64\package-set\desktop-packages
apps\desktop\.desktop-build\targets\win-x64\packed\dsh

其中包含：

deepseek-ai-dsh-deepseek-account-0.1.7-alpha.1.tgz
deepseek-ai-dsh-deepseek-account-platform-0.1.7-alpha.1.tgz

也就是说，不带 -platform 的：

deepseek-ai-dsh-deepseek-account-0.1.7-alpha.1.tgz

这次构建中确实存在。

最终 ASAR 内容

随后检查了：

apps\desktop\.desktop-build\targets\win-x64\unsigned-artifacts\win-unpacked\resources\app.asar

分别查看 Electron shell 根层：

app.asar\node_modules

以及 dsh runtime：

app.asar\dsh\node_modules

得到以下结果：

node_modules         dsh-deepseek-account     false
dsh\node_modules     dsh-deepseek-account     true

node_modules         cordis                   false
dsh\node_modules     cordis                   true

node_modules         dsh-app-boot             false
dsh\node_modules     dsh-app-boot             true

node_modules         dsh-home-paths            false
dsh\node_modules     dsh-home-paths            true

也就是：

app.asar\dsh\node_modules\@deepseek-ai\dsh-deepseek-account

存在。

app.asar\dsh\node_modules\@deepseek-ai\cordis

存在。

app.asar\dsh\node_modules\@deepseek-ai\dsh-app-boot

存在。

app.asar\dsh\node_modules\@deepseek-ai\dsh-home-paths

也存在。

但对应的包在：

app.asar\node_modules\@deepseek-ai\...

下都不存在。

启动时报错的位置

之前原版 packaged Desktop 启动时报错时，异常来源是：

resources/app.asar/lib/main.js

最先看到的是：

ERR_MODULE_NOT_FOUND:
Cannot find package '@deepseek-ai/dsh-deepseek-account'

把 dsh-deepseek-account 临时加入 Desktop production dependencies 后，再次启动时继续出现：

ERR_MODULE_NOT_FOUND:
Cannot find package '@deepseek-ai/cordis'

以上是这次重新从原版构建后检查到的实际结果，希望对后续排查有帮助。