# 桌面端 0.1.7-alpha.1 启动即崩：壳层 asar 缺失 peerDependency @deepseek-ai/cordis

[btsd321]

摘要

0.1.7-alpha.1 的 Desktop 打包产物（package:win:x64 -- --unsigned --dir）在安装目录启动时，主进程立即抛出：

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@deepseek-ai/cordis'
imported from D:\<安装目录>\resources\app.asar\node_modules\@deepseek-ai\dsh-api-gateway\lib\index.js

根因是壳层（shell）node_modules 中打包了 dsh-api-gateway / dsh-typert-protocol，但它们的 @deepseek-ai/cordis 依赖以 workspace:^ 声明在 peerDependencies/devDependencies 中，electron-builder 不会安装 peer 依赖，导致 asar 壳层缺包。cordis 实际只存在于 asar 内的 /dsh/node_modules/ 树，壳层模块按 Node 解析规则无法到达。0.1.6-alpha.2 同路径构建可正常启动，属 0.1.7 引入的回归；现有冒烟与 CI 均不覆盖壳的 GUI 主入口，因此未被拦截。

环境

• Windows 11 Pro 10.0.26200，x64
• master c36a83ff6b（dsh / Desktop 0.1.7-alpha.1）
• 构建模式：pnpm --dir apps/desktop run package:win:x64 -- --unsigned --dir
• 触发方式：将 win-unpacked 复制到安装目录后双击 DeepSeek Harness.exe

现象

弹出 Electron 原生错误框"A JavaScript error occurred in the main process"，内容为上述 ERR_MODULE_NOT_FOUND，应用无法启动。

排查过程与证据

1. 排除复制问题

安装目录的 app.asar 与构建产物 unsigned-artifacts/win-unpacked/resources/app.asar 条目数一致（均 16595 条），内容同源，排除复制损坏。

2. asar 内 cordis 的位置

/dsh/node_modules/@deepseek-ai/cordis/package.json     ← 存在（dsh 运行时树）
/node_modules/@deepseek-ai/cordis/                      ← 不存在（壳层）

壳层 /node_modules/@deepseek-ai/ 下仅有：cosmokit、dsh-api-gateway、dsh-brand、dsh-deque、dsh-timeout、dsh-typert-protocol、schemastery。

3. 报错来源文件确实静态 import cordis

// asar 内 /node_modules/@deepseek-ai/dsh-api-gateway/lib/index.js
import { Service, symbols } from "@deepseek-ai/cordis";

// asar 内 /node_modules/@deepseek-ai/dsh-typert-protocol/lib/index.js
import { Context, Service } from "@deepseek-ai/cordis";

4. cordis 的依赖声明位置（asar 内 dsh-api-gateway 的 package.json）

{
  "dependencies": { "...": "不含 cordis" },
  "devDependencies": { "@deepseek-ai/cordis": "workspace:^", "...": "..." },
  "peerDependencies": { "@deepseek-ai/cordis": "workspace:^", "...": "..." }
}

workspace:^ 在仓库内由 pnpm 链接到 vendor/cordis，开发态解析正常；electron-builder 收集壳层生产依赖时不包含 peer/dev 依赖，故打包后缺失。Node 从壳层模块向上解析时不会进入平级的 /dsh/node_modules 树，因此必然失败。

5. 为什么冒烟和 CI 没有拦住

• smoke-packaged-runtime 以 ELECTRON_RUN_AS_NODE 方式启动打包产物内的 Host（模块图在 /dsh/node_modules 树内，cordis 就在旁边），并验证 Office 转换等能力；从未以 GUI 应用身份执行壳的主入口（lib/main.js → 壳层依赖图）
• 0.1.6-alpha.2 的壳层依赖图不经过壳级 dsh-api-gateway（或 cordis 曾被包含），同路径可启动；0.1.7 的壳依赖图变化（如 "fix(desktop): move host out of CLI package"）引入了这条未打包的 peer 依赖链

免重打包的临时 workaround（已验证可正常启动）

Node 从 asar 内部解析失败后会回落到真实文件系统继续向上查找（asar 根 → resources/node_modules → 安装根 node_modules → …）。因此在安装根目录放置真实包目录即可补齐：

<安装目录>/node_modules/@deepseek-ai/cordis/          ← 从 asar 的 /dsh/node_modules/@deepseek-ai/cordis 解出
<安装目录>/node_modules/@deepseek-ai/cosmokit/        ← cordis 的运行时依赖（asar 壳层顶层有，解出复用）
<安装目录>/node_modules/@standard-schema/spec/        ← 同上

cosmokit 与 @standard-schema/spec 均无运行时依赖，三个目录放好后启动即恢复正常。解包可用 @electron/asar 的 extractAll。

排查工具提示：该 asar 头部条目路径分隔符为反斜杠，@electron/asar 的 extractFile 必须传入原始路径字符串；将 listPackage 结果规范化为斜杠后直接用于 extractFile 会静默抛 "not found"。

修复建议

任选其一：

1. 打包侧补齐壳层 peer 依赖：在 electron-builder.config.mjs 的依赖收集/files 规则中，将壳层模块图的 peerDependencies（至少 @deepseek-ai/cordis）纳入壳层 node_modules；或在壳依赖链的相关包中将 cordis 提升为 dependencies
2. 壳入口彻底 bundle：让 apps/desktop 的 tsdown 构建不将 workspace 依赖标记为 external，壳主入口不依赖 asar 内散装的 workspace 包
3. 补启动冒烟（治本）：在 smoke-packaged-runtime 中增加"以 GUI 应用身份启动打包产物、等待主窗口创建成功后退出"的检查。当前冒烟只覆盖 Host，壳主入口的任何缺包/崩溃都无法被 CI 拦截——本次回归正是由此漏过

最小复现步骤

# 1. 打包
pnpm --dir apps/desktop run package:win:x64 -- --unsigned --dir

# 2. 复制 win-unpacked 到任意目录并启动
cp -r apps/desktop/.desktop-build/targets/win-x64/unsigned-artifacts/win-unpacked <安装目录>
"<安装目录>/DeepSeek Harness.exe"
# → 主进程 ERR_MODULE_NOT_FOUND: @deepseek-ai/cordis

# 3. 验证缺包（可选）
node -e "const asar=require('@electron/asar');const l=asar.listPackage('<安装目录>/resources/app.asar');
console.log(l.filter(p=>p.includes('cordis')&&!p.includes('cordis-')).slice(0,3));
console.log(l.filter(p=>p.startsWith('\\node_modules\\@deepseek-ai\\cordis')).length)  // 0"