DSH 0.1.6-alpha profile 模块解析缺陷：require('包名/') 触发 resolve.paths 崩溃

[ShiraKawaYZK]

DSH 0.1.6-alpha profile 模块解析缺陷：require('包名/') 触发 resolve.paths 崩溃

环境

• DSH：@deepseek-ai/dsh 0.1.6-alpha.2（npm latest 是 0.1.5-rc.2，即升级前版本）
• boot 层：@deepseek-ai/dsh-app-boot 0.1.6-alpha.2
• Node：v24.19.0
• 系统：Windows 11
• profile：web
• 受影响插件：dsh-office-toolkit 0.3.28（第三方插件，未做任何修改）

现象

从 0.1.5-rc.2 升级到 0.1.6-alpha.2 之后，任何懒加载 ExcelJS 的插件工具都会失败，报错原文是 createRequire.resolve.paths is not a function or its return value is not iterable。

同一个插件在纯 Node 进程里直接调用自身核心函数（opRead() 读同一个 .xlsx）完全正常，只在 DSH 进程内失败，说明问题在宿主侧的模块解析。

插件侧还会把它二次误报成缺少依赖，掩盖真实原因：缺少依赖 process/(用于:Excel 读写) ... 原始报错: Cannot find module 'process/'。

最小复现

const { isBuiltin, createRequire } = require('node:module')

isBuiltin('process/')                                // false —— 尾斜杠导致不算内建
createRequire(__filename).resolve.paths('process')   // null  —— 内建名返回 null
for (const p of createRequire(__filename).resolve.paths('process')) {}
// TypeError: createRequire.resolve.paths is not a function or its return value is not iterable

纯 Node 下 require.resolve('process/') 会正常解析到 npm polyfill 包 node_modules/process/index.js。readable-stream 正是刻意用这个尾斜杠写法（require('process/')、require('string_decoder/')）来强制走 polyfill 而不是内建。

根因（源码位置）

文件：packages/boot/app-boot/src/profile-resolution/resolver.ts

1. barePackageName()：isBuiltin(request) 只判断了原始请求，切掉子路径之后没有重新判断，于是 'process/' 被归约成 'process'，也就是一个内建名。
2. 两处 resolve.paths 调用（约 L165、L350）：as string[] 只是类型断言，运行时没有兜底；resolve.paths() 对内建名返回 null，for...of null 直接抛 TypeError。

同一个文件里 packageDirFromAnchor 写的是 ... ?? []，说明作者本意就是要防这种情况，只是这两处漏了。

建议改动

// 1) 切片后重新判内建名：这类请求交回 Node 原生解析
//    （原生解析能正确把 'process/' 解析到 npm polyfill 包）
if (request[0] !== '@') {
  const bare = first < 0 ? request : request.slice(0, first)
  if (isBuiltin(bare)) return
  return bare
}

// 2) 运行时兜底（与 packageDirFromAnchor 的写法保持一致）
for (const searchPath of createRequire(parent).resolve.paths(name) ?? []) {

影响面

任何依赖树里出现「内建名 + 子路径」这种 polyfill 写法的插件都会中招。readable-stream 极为常见，其下游包括 exceljs、@wekanteam/exceljs、jszip、unzipper、archiver、duplexer2、lazystream 等。

回归说明

标签 dsh-v0.1.5-rc.2 下 packages/boot/app-boot/src/ 只有 index.ts 与 profile.ts，不存在 profile-resolution/ 目录。该模块解析子系统是 0.1.6-alpha 新引入的，因此这是新引入的回归，而不是老问题。

临时绕行（用户侧）

在本机的 lib/index.js 与 lib/worker/profile-resolution-bootstrap.js 两个构建产物上打同等补丁即可恢复；DSH 升级后会覆盖，需要重打。

// lib/index.js 与 lib/worker/profile-resolution-bootstrap.js（构建产物）
// 1) 各调用点加运行时兜底
for (const searchPath of (createRequire(parent).resolve?.paths?.(name) ?? [])) {
// 2) barePackageName 切片后重判内建名
if (request[0] !== "@") {
  const bare = first < 0 ? request : request.slice(0, first);
  if (isBuiltin(bare)) return;
  return bare;
}

---

English summary

Upgrading DSH from 0.1.5-rc.2 to 0.1.6-alpha.2 broke any plugin tool that lazily imports ExcelJS, failing with createRequire.resolve.paths is not a function or its return value is not iterable.

Root cause is in the new profile module resolver, file packages/boot/app-boot/src/profile-resolution/resolver.ts:

1. barePackageName() does not re-check isBuiltin() after stripping the subpath, so 'process/' is reduced to the builtin name 'process'.
2. Both call sites iterate createRequire(parent).resolve.paths(name) as string[] with no runtime guard; require.resolve.paths() returns null for builtin names, and for...of null throws.

The 'process/' and 'string_decoder/' specifiers come from readable-stream, which deliberately uses the trailing slash to force the npm polyfill package over the builtin. Plain Node resolves 'process/' to node_modules/process/index.js without issue.

Suggested fix: re-check isBuiltin(bare) after slicing, and use ?? [] at both call sites (the same file already does this in packageDirFromAnchor). The resolver subsystem is absent from tag dsh-v0.1.5-rc.2, so this is a fresh regression introduced in 0.1.6-alpha.

[Sabraker]

补充一个更新版本上的复现：0.2.0-rc.2（当前最新 prerelease，桌面版）仍受影响

环境：Windows 11 x64；@deepseek-ai/dsh-desktop 0.2.0-rc.2（Electron 44.0.0 / Node 24.18.1）；dsh-office-toolkit@0.3.31；profile = desktop。

触发：首次调用插件的 office_write_xlsx（懒加载 ExcelJS 的路径）即失败：

createRequire.resolve.paths is not a function or its return value is not iterable

插件侧内置的诊断把它归因到 require('process/') / require('string_decoder/') 的尾斜杠写法，与主贴一致。

同一插件同一环境下不受影响的路径（都已实测通过）：office_write_docx、office_read（含 withFormatting）、office_query（对 CSV 做分组聚合）⇒ 只有走 ExcelJS 的 xlsx 路径失败，与主贴「.csv / .docx 正常」的结论吻合。

结论：主贴建议的两处改动（① 切掉子路径后重新判内建名；② resolve.paths(name) ?? []）在 0.2.0-rc.2 上仍然必要 —— barePackageName() 里"只在切子路径前判内建名"的这条路径没有被修掉。

另外一点观察：这个报错在插件侧会被二次包装成「缺少依赖 process/」，容易把排查引向"装依赖/重装"，而真实原因在宿主的模块解析。如果宿主能对 resolve.paths() 返回 null 的情况做兜底（或把这类「内建名 + 尾斜杠」的请求交回 Node 原生解析），下游插件就不必各自识别这个场景了。