profile 解析器两处缺陷导致所有带依赖的第三方插件无法加载

[taotaao]

[Bug] profile 解析器两处缺陷导致所有带依赖的第三方插件无法加载

环境

• DSH runtime: 0.2.0-rc.2（dsh --version）
• 桌面端: Electron app 44.0.0，Windows 11 (10.0.26200)，win-x64
• profile: desktop（~/.dsh/profiles/desktop）
• 插件: dsh-minecraft@0.12.4（npm，dsh.bundle.patch 类型）
• 该插件已通过 dsh plugin allow-version 授予精确版本豁免

问题概述

任何安装了自己依赖的第三方 profile 插件，在 import 自身依赖时都会崩溃。
插件本身没有问题 —— 同一份代码在纯 Node 下（ELECTRON_RUN_AS_NODE=1）用
import() 直接加载并连接 Minecraft 服务器，完全正常。

问题出在 0.2.0-rc.2 新增的 profile 模块解析层。
它注册了 ESM/CJS 两条 loader hook，把 profile 内的裸导入改道到内存路由，
而该路由在两处偏离了 Node 原生行为，且都触发了异常。

Bug 1: resolve.paths() 缺少 ?? [] 兜底

位置

• dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/worker/profile-resolution-bootstrap.js
  • nativePackageDir() 第 136 行附近
  • routeScoped() 第 311、364 行附近
• dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js（同一份解析器的另一处副本）第 1249、1424、1477、2021、3265 行附近
• dsh/node_modules/@deepseek-ai/dsh-plugin-package-inventory-deepseek/lib/index.js 第 47 行附近
• dsh/node_modules/@deepseek-ai/dsh-plugin-package-inventory-deepseek/lib/types/index.js 第 49 行附近

代码

function nativePackageDir(parent, name) {
  for (const searchPath of createRequire(parent).resolve.paths(name)) {   // ← 无兜底
    ...
  }
}

// routeScoped() 内（profile 层对所有裸导入无条件执行）
for (const searchPath of createRequire(parent).resolve.paths(name)) {     // ← 无兜底
  if (!searchPath.startsWith(layer.localPrefix)) break;
  ...
}

报错

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

（V8 对 for...of 报错时会省略调用参数，所以文案里看不到 (parent) / (name)。
我用同样的表达式形式在本机复现，拿到的文案逐字一致，确认崩溃点就是上面这行。）

佐证：作者自己在别处都做了兜底

// ✅ dsh-app-boot/lib/index.js  packageDirFromAnchor()
for (const searchPath of createRequire(anchor).resolve.paths(packageName) ?? []) {

// ✅ libreoffice-kit
return (require.resolve.paths(name) ?? []).some(...)

也就是说 resolve.paths 在该运行时下确实可能返回 null，
但 profile 解析器里的调用点漏掉了兜底。

Bug 2: barePackageName() 把"尾随斜杠的内置模块"误判为普通包

位置

• dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/worker/profile-resolution-bootstrap.js 第 53 行附近
• dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js 第 1166 行附近

代码

function barePackageName(request) {
  if (!request || request[0] === "." || ... || isBuiltin(request)) return;  // ← 尾随斜杠骗过检查
  const first = request.indexOf("/");
  if (request[0] !== "@") return first < 0 ? request : request.slice(0, first);
  ...
}

问题

表达式	原生 Node	isBuiltin()
require('process')	返回内置模块	true
require('process/')	也返回内置模块	false

readable-stream@4.8.0 的 lib/internal/shims/process.js 里写的是
require('process/')（作者注释说明是为了绕开某些 polyfill，见 readable-stream #539）。
由于 isBuiltin('process/') 为 false，barePackageName 返回 "process"，
该请求被送进路由；合成解析器又找不到 'process/'：

Error: Cannot find module 'process/'
Require stack:
- .../readable-stream/lib/internal/shims/process.js
- .../protodef/src/serializer.js
- .../minecraft-protocol/src/transforms/compression.js
- .../mineflayer/lib/loader.js
    at resolveRoutedCjs (dsh-app-boot/lib/index.js:1741:28)
    at Module.wrappedFilename [as _resolveFilename] (dsh-app-boot/lib/index.js:1806:16)

复现步骤

1. 在 profile 里安装任意带自身依赖的第三方插件（本例 dsh-minecraft），
   依赖会被 pnpm 以 hoisted 方式装进 <profile>/node_modules
2. 启动 DSH，让插件注册一个会 await import('<它的依赖>') 的工具
3. 调用该工具 → 命中 Bug 1
4. 修掉 Bug 1 后重试 → 命中 Bug 2

建议修法

// Bug 1: 与作者在 packageDirFromAnchor() 里的写法保持一致
for (const searchPath of createRequire(parent).resolve.paths(name) ?? []) {

// Bug 2: 判内置时忽略尾随斜杠，通用覆盖所有同类情况
if (... || isBuiltin(request.replace(/\/+$/, ""))) return;

影响面

• 不是 Minecraft 插件特有的问题：任何带 dependencies 的第三方 profile 插件都会踩到
• 内置插件不受影响，因为它们位于 installation 路径，不走 profile 层的路由分支 ——
  这大概也是问题没被更早发现的原因
• 附带说明：resolve.paths 缺少兜底这一点，从仓库里既有 ?? [] 又有遗漏来看，
  可能值得整体排查一遍同类调用点

我已做的验证

在本地对 app.asar 做了原地字节级补丁（未重新打包，因为该 asar 含 1497 个
unpacked 文件，含 LibreOffice 与 koffi 原生模块），改动仅 12 处、文件大小不变、
node --check 通过、全盘差异仅落在目标文件内。打完后插件完全正常：
成功连接 Minecraft 1.20.4 服务器、读取世界状态、砍树、合成工作台与木镐、挖掘圆石。

附：如何从崩溃现场确认 Bug 1 的崩溃点

在 profile-resolution-bootstrap.js 里用 ?? [] 兜底后，报错从
createRequire.resolve.paths is not a function...
变成 Cannot find module 'process/' —— 即 Bug 2。两者是独立缺陷。

[PerryLink]

两处缺陷我都复核了，在最新代码上仍未修，而且我能在本机把崩溃文案逐字复现。但有一条关键事实要更正 —— 它要是不改，维护者一句"原生 Node 也解析不到"就能把报告挡回去。

1. 两处缺陷的位置

缺陷 A —— 尾随斜杠绕过内置判定（packages/boot/app-boot/src/profile-resolution/resolver.ts:146-150）：

export function barePackageName(request: string): string | undefined {
  if (!request || request[0] === '.' || request[0] === '/' || request[0] === '\\'
    || request[0] === '#' || request.includes(':') || isBuiltin(request)) return
  const first = request.indexOf('/')
  if (request[0] !== '@') return first < 0 ? request : request.slice(0, first)

isBuiltin(request) 用的是 Node 的 isBuiltin。本机实测（node v22.22.3 与 v24.21.0 同结果）：

isBuiltin('process')      = true
isBuiltin('process/')     = false      ← 尾随斜杠让它漏过去
isBuiltin('fs/promises')  = true
⇒ barePackageName('process/') === 'process'

缺陷 B —— 三处 as string[] 断言，没有运行期兜底：

• resolver.ts:247 → for (const searchPath of createRequire(parent).resolve.paths(name) as string[]) {（nativePackageDir）
• resolver.ts:470 → 同型（routeScoped，紧接 :471 的 startsWith(layer.localPrefix)）
• resolver.ts:523 → const searchPaths = flavor === 'esm' ? ancestors : createRequire(parent).resolve.paths(name) as string[]

resolve.paths(name) 只对 builtin 名返回 null。本机实测该表达式的 for…of 报错：

TypeError: req.resolve.paths is not a function or its return value is not iterable

与你引的 V8 文案同一族 ⇒ 崩溃点确认就是这三行。

两处不是彼此独立，而是缺陷 A 是缺陷 B 的唯一可达触发器：resolve.paths 只对 builtin 返回 null，而 barePackageName 正常已用 isBuiltin 过滤 ⇒ 能走到那三行的 builtin 名，只可能来自 A 漏掉的尾随斜杠写法。两处都要修，但因果关系要在报告里写清 —— 这决定了修复顺序与测试落点。

2. ⭐ 必须更正的一条：原生 Node 不把 require('process/') 当内置模块

你写「原生 Node：require('process/') 也返回内置模块」。这条是错的。 本机在 DSH 支持的整个区间（engines: ^22.19.0 || >=24.0.0）实测：

node -e "require('process/')"
→ Error: Cannot find module 'process/'

除非 node_modules/process 存在 —— 这时解析到的是 npm 上的 process polyfill 包，不是内置模块。

正确的表述是：

Node 的 Module._findPath 会先剥掉尾随斜杠再做普通包查找，所以 process/ 被当成包名 process 去找磁盘上的包；而 resolve.paths('process') 仍按 builtin 返回 null。这个不对称才是 bug 的来源 —— DSH 的路由层把请求当裸包名 process 处理，于是走进那条只为 builtin 才会返回 null 的路径。

这个不对称我实测过：createRequire(entry).resolve('process/') → <tmp>/node_modules/process/index.js（npm polyfill），而 resolve.paths('process') → null。

顺带把链路补全，解释为什么这个包一定会被装上：readable-stream@4.8.0 的 lib/internal/shims/process.js 首行就是 require('process/')，而它的 package.json 的 dependencies 含 "process": "^0.11.10" ⇒ 任何依赖 readable-stream@4 的插件都会把 process 装进 profile，请求必然发生。

3. 仓库自己已经有正确写法（这条最有利于被采纳）

packages/boot/app-boot/src/profile.ts:691-694：

// resolve.paths returns null only for builtins, which no bundle name is.
for (const searchPath of createRequire(anchor).resolve.paths(packageName) ?? []) {

⇒ 同一仓库里已经有人想到这个 null 并用了 ?? []。你的"值得整体排查一遍"是对的，我数了一下：已兜底 7 处（profile.ts:694、test-support/client-runtime/src/assembly/bundle-roster.ts:135、test-support/session-snapshot/src/launcher.ts:380、scripts/release/installed-product-isolation.ts:68、apps/cli/tests/profiles/packed-installation.ts:156、scripts/libreoffice-packages.mjs:50、packages/boot/app-boot/tests/linked-resolution-matrix.spec.ts:403/426），未兜底 5 处（resolver.ts:247/470/523、compatibility-preflight.ts:38、profile-resolution/service.ts:138，另 llm/plugin-package-inventory-deepseek/src/index.ts:79 同型）。

⇒ 报告里可以直接写："照 profile.ts:694 的写法补齐这 5 处" —— 这比"请修 bug"更容易过。

4. 还有一个你没提的坑：补了 ?? [] 也还是失败

你说补 ?? [] 之后仍报 Cannot find module 'process/'。原因我定位到了：回退锚点 layer.nativeAfter（resolver.ts:192-200 的 computeProfileLayer，:197 nativeAfter: join(profileParent, 'package.json')，而 profileParent = dirname(dir)）在 profile 目录之上。

本机实测 Module._nodeModulePaths('<home>/.dsh/profiles')：

[ <home>/.dsh/profiles/node_modules, <home>/.dsh/node_modules, <home>/node_modules, … ]

不含 <home>/.dsh/profiles/desktop/node_modules —— 所以即使不抛 TypeError，也找不到 profile 里那个 process 包。这正好对上你日志里栈顶的 resolveRoutedCjs（resolver.ts:812-828，:821-823 synthetic.paths = cjs._nodeModulePaths(dirname(anchor))）。

⇒ 只补 ?? [] 是不够的，两处都得修才算完整。

5. 建议的修法

// resolver.ts:147-148 —— 先规范化尾随斜杠再判内置
if (!request || request[0] === '.' || request[0] === '/' || request[0] === '\\'
  || request[0] === '#' || request.includes(':')
  || isBuiltin(request.replace(/\/+$/u, ''))) return

这一步同时消除缺陷 B 的可达路径，所以它比补 ?? [] 更根本；但两处都建议改（B 是纵深）。

最小复现：profile 内装任意依赖 readable-stream@4 的插件 → require('process/')；或者直接 createRequire(x).resolve.paths('process') 观察 null。

修好后的验证点：require('process/') 应解析到 <profile>/node_modules/process/index.js（npm polyfill），不是内置 process；Cannot find module 'process/' 消失。

用户侧临时绕过：插件里改用 require('node:process')（带 : 会被 resolver.ts:148 的 request.includes(':') 直接放行），或把上层依赖降到 readable-stream@3。

6. 版本确认：未过期、也未修

你写 0.2.0-rc.2。resolver.ts 的这些行在 dsh-v0.2.0-rc.2 上同样存在（:145/244/471/524，源文件从 rc.2 到 master 仅 10 增 11 删且不涉及这些行），而 origin/master = d743267388（= dsh-v0.2.1-alpha.2）上仍未修。

你看到的"两份副本"（worker/profile-resolution-bootstrap.js 与 lib/index.js）是同一份源码的两处打包产物 —— profile-resolution/worker-bootstrap.ts 只有 8 行，installRuntimeInterception 来自同一个 resolver.ts。所以不需要当成两个实现分别排查。

[taotaao]

谢谢复核，尤其是第 2 点 —— 那条我确实写错了，而且错得比"记错一条事实"更严重：我的实验环境被污染了。

我的错误根源（供其他人避坑）

我当时在 mc-bot/ 目录里做的实验 —— 那个目录 npm install 过 mineflayer，所以 node_modules/process@0.11.10 恰好存在。

环境	require('process/')	我的错误结论
污染目录（有 process polyfill）	解析到 polyfill，成功	"原生 Node 也返回内置" ❌
干净临时目录（无 node_modules）	MODULE_NOT_FOUND: Cannot find module 'process/'	你的说法正确 ✅

更要紧的是：process@0.11.10 导出的是全局 process 对象，所以即使解析到 polyfill，require('process/') === process 依然为 true —— 任何"比较引用"的自检都会通过。这大概也是这个 bug 一直没被更早发现的原因之一。

补充两条可能对你有用的实测数据

① resolve.paths 的不对称，双侧都测了（node v24.21.0，干净目录）：

表达式	结果
resolve.paths("process")	null
resolve.paths("process/")	数组(6 项)
resolve.paths("fs")	null
resolve.paths("fs/")	数组(6 项)

即：尾随斜杠不仅绕过 isBuiltin，还让 resolve.paths 从 null 变成一个正常数组 —— 所以缺陷 A 的作用方式是"把一个本该被过滤掉的请求，变成一个有路径可查的普通包名"。

② 你提的验证点我实测了（在 profile 内插件的位置做 createRequire，不经路由层）：

resolve("process")  = process
resolve("process/") = <profile>/node_modules/process/index.js

符合你的预期。这确认了：只要让 process/ 走原生解析就能成功（原生会剥掉尾随斜杠、找到 profile 里的 polyfill）；而不修 A、只补 ?? [] 时会落到 nativeAfter 锚点、_nodeModulePaths 不含 profile 的 node_modules —— 所以"两处都得修、但 A 更根本"的判断，在我这边完全成立。

我这边已按建议改过并跑通

在 0.2.0-rc.2 上，我改的是 app.asar 内联字节级补丁（未重打包）。实际改动等价于你那句，但我打的时候没加 u flag：

|| isBuiltin(request.replace(/\/+$/, ""))) return

补完之后，dsh-minecraft@0.12.4 下列操作都跑通了：连接服务器、mc_observe 读方块、mc_dig 挖方块、顺序合成（木镐 → 石镐）、走完一次石镐工具链。这期间没有再出现 TypeError 或 Cannot find module 'process/'。所以只改 A 这一处，对这个具体插件已经够了 —— 与你"B 是纵深防御"的判断一致。

（后来那个 MC 服务器进程被终止，是另一个原因：安装插件会重载插件树，把会话起的后台子进程一起带走，与本次缺陷无关。）

但 0.2.1-rc.5 依然未修

我核对了 rc.5 的新包（dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js，203,468 字符），缺陷 A 原样存在：

isBuiltin(request)                    ← 未加尾随斜杠规范化
resolve.paths(packageName) ?? []      ← 这一处有兜底（原本就有）
resolve.paths(name)                   ← 无兜底
resolve.paths(bare)                   ← 无兜底

我能确认的是：0.2.0-rc.2 和 0.2.1-rc.5 这两个版本都有这个问题（中间的小版本我没有逐一核对）。

另外有一条我无法确证、但值得你留意：我所在的环境升级到 rc.5 之后，出现过一个现象 —— 所有依赖 readable-stream@4 的第三方插件都加载失败，DSH 表现为插件报错、消息发不出去，把这些插件从 bundles 移除后恢复正常。我推测这与本缺陷有关（因为移除的恰好是唯一引入 readable-stream@4 的插件），但没有做进一步隔离验证，所以只作为线索提供，不作为结论。

如果这个推测成立，那么影响面就不只是"某个插件不能用"，而是"用户升级后集体失去所有含 readable-stream@4 依赖的插件"。

两点想请教

1. 你说"照 profile.ts:694 补齐这 5 处"是最容易被采纳的写法 —— 那 compatibility-preflight.ts:38 和 profile-resolution/service.ts:138 这两处，补 ?? [] 之后语义上会不会把"真的找不到包"和"builtin 返回 null"混在一起？还是说这两处本来就只处理非 builtin 名，所以 ?? [] 是安全的？

2. 修复之后，barePackageName('process/') 会返回 undefined → 该请求完全交给原生解析。那像 readable-stream@4 这种故意依赖 process/ 指向 polyfill 的写法，在 profile 里还能正常拿到 polyfill 吗？我这边实测是可以（见上面第 ② 条），但想确认这不是我环境的偶然。

再次感谢 —— 那份报告如果没有你这条更正，基本会被一句"原生 Node 也解析不到"驳掉。

[GodLike2020]

感谢这条帖子的完整分析，也感谢 #8674 的探针复现。我不是来重复报 bug 的：我是 dsh-mqtt-tools 的作者，本机在桌面版 0.2.1-rc.5 上遇到同一个错误；按 #8674 的隔离思路复现后，把版本范围推到 0.2.2-alpha.2，并做了一个 3 文件、+17/−8 的上游补丁，构建态验证通过。

这个问题从 9 月到现在至少已有 10 条同源报告（#7031、#7377、#7903、#8250、#8674、#8986、#9318、#10387……），散在讨论区里，单独看每条都不完整。我把能减少你们决策成本的部分集中在这里，不做优先级上的要求。

TL;DR：resolve.paths 崩溃在 0.2.2-alpha.2 上仍复现；根因与 #9318 一致；一个 3 文件、+17/−8 的补丁已在构建产物上验证（pristine 全新 profile 失败 / patched 同一 profile 成功 / patched 另一全新 profile 一步安装成功）；只差确认修法方向（下面 §5 的 A 还是 B），之后我可以补测试，或按你们格式给最小补丁。

1. 最新版本仍复现（隔离环境，2 分钟可跑）

环境：Windows 11 / 内置 Node 24.21.0 / npm 安装 @deepseek-ai/dsh@0.2.2-alpha.2（tag dsh-v0.2.2-alpha.2 = f3803c96）/ 全新隔离 DSH_HOME / 全新 profile（--from-default-profile web）：

node node_modules/@deepseek-ai/dsh/lib/bin.js --profile clean --from-default-profile web --dump-config
node node_modules/@deepseek-ai/dsh/lib/bin.js plugin --profile clean add dsh-mqtt-tools@0.3.12 --save-exact
node node_modules/@deepseek-ai/dsh/lib/bin.js clean --no-open --port 53995
# 另开终端
curl http://127.0.0.1:53995/dsh-mqtt-tools/api/state

返回：

"library": { "mqtt": false, "aedes": false,
  "error": "createRequire.resolve.paths is not a function or its return value is not iterable" }

broker.library.error 是同一根因在 ESM→CJS 翻译器里的包装：This is caused by either a bug in Node.js or incorrect usage of Node.js internals...。栈指向 routeScoped (…/dsh-app-boot/lib/index.js:1718:58)（0.2.1-rc.5 是 1628，0.1.7-rc.2 是 1422）。

版本	结果
0.2.1-rc.5（桌面公开版）	复现（本机）
0.2.2-alpha.2（npm alpha）	复现（上面这套）
master ce7073d5 / tag f3803c96	源码仍未修：5 处 resolve.paths(...) as string[] 无判空（第 3 节）

触发链：dsh-mqtt-tools@0.3.12 → mqtt@5.16.1 → readable-stream@4.8.0，lib/internal/shims/process.js:18 的 require('process/')（另有 lib/internal/streams/readable.js:70 的 require('string_decoder/')）。readable-stream 的 deps 明确含 process ^0.11.10、string_decoder ^1.3.0，尾斜杠是刻意的 polyfill 引用；同类触发链还有 jsdom→tr46→punycode/、exceljs、minecraft-protocol、bl、concat-stream（readable-stream 周下载约 4.9 亿，影响面不小）。

2. 根因补充（与 #9318 / PerryLink 的复核一致）

barePackageName('process/') 归一为 process；isBuiltin('process/') === false 放行；resolve.paths('process') 对内置名返回 null → for…of null 抛 TypeError（V8 把“不是函数”和“返回值不可迭代”合并成一句，文本会误导人以为 API 不存在）。

单独加 ?? [] 不够，#8674 已实测：routeScoped 会落到 native-after-interception，锚点是 dirname(profileDir)/package.json（~/.dsh/profiles/package.json），搜索链不含 profile 自己的 node_modules → 错误前进成 Cannot find module 'process/'。

3. 补丁：把 Node 实际收到的 request 原样交给 resolve.paths

思路：resolve.paths() 的入参应该是原始 request，不是归一化后的 name。resolve.paths('process') → null（内置名）；resolve.paths('process/') → 正常搜索链（目录请求属于普通包查找）。这样 candidates 能命中 <profile>/node_modules/process，路由结果是 native + 该 packageDir，最后由 Node 用原始 request + 真实 parent 解析到 polyfill 包，语义与原生 Node 一致，也不需要“加斜杠重试”这类启发式。

另一个实测结论：对非内建 specifier，resolve.paths(name) 与 resolve.paths(request) 返回完全相同的 14 条路径（测过 mqtt、mqtt/、mqtt/build/lib/client.js、aedes、readable-stream、@types/node）→ 正常请求零行为变化。

// packages/boot/app-boot/src/profile-resolution/resolver.ts
/**
 * The `node_modules` positions Node's own resolver would search for `request`
 * from `parent`. Pass the request exactly as Node receives it: `resolve.paths()`
 * returns null for a bare builtin name (`process`), while a directory request
 * (`process/`) is an ordinary package lookup.
 */
export function nodeLookupPaths(parent: string, request: string): readonly string[] {
  return createRequire(parent).resolve.paths(request) ?? []
}

替换 5 处无判空调用（第 6 处 profile.ts:632 原本已有 ?? []，保持不动）：

文件	位置	传参
resolver.ts	nativePackageDir L276	name
resolver.ts	routeScoped L591（当前唯一触发点）	request
resolver.ts	routeLinked CJS 分支 L644	request
profile-resolution/service.ts	packageDirFromParent L143	name
compatibility-preflight.ts	manifestOf L38	bare

同时删掉 5 处 as string[]：@types/node 里 resolve.paths(request): string[] | null，这个断言把 null 藏过了 tsc；删掉后编译器会直接标出全部调用点。worker 侧不用单独改：worker-bootstrap.ts 只是 import { installRuntimeInterception } from './resolver.ts'，构建时同步。

git apply --stat：3 files changed, 17 insertions(+), 8 deletions(-)。完整 dsh-app-boot-fix.patch 见本楼附件。

如果你们想先要最小版：只改 routeScoped 一处 + helper，就是单个文件、十几行（helper 约 9 行 + 站点 1 行替换），也能消除当前所有已知触发（routeLinked 的 CJS 分支只在 entries 命中时才可达，nativePackageDir/packageDirFromParent/manifestOf 那三处是同型隐患）。另外据 #9318，dsh-plugin-package-inventory-deepseek 里也有同型调用（lib/index.js:47、lib/types/index.js:49），本补丁未覆盖，可以按需要一并处理。

4. 验证（改的是构建产物，不只是源码）

在隔离安装的 0.2.2-alpha.2 上，对 dsh-app-boot/lib/index.js（202809→203117B，1 个 helper 定义 + 5 个站点）与 lib/worker/profile-resolution-bootstrap.js（37385→37719B，4 处）打等价补丁：

场景	state.library
pristine 运行时 + 全新 profile + 一步安装	{"mqtt":false,"aedes":false,"error":"createRequire.resolve.paths is not a function or its return value is not iterable"}
patched 运行时 + 同一 profile 重启	{"mqtt":true,"aedes":true,"error":null}
patched 运行时 + 另一个全新 profile + 一步安装	{"mqtt":true,"aedes":true,"error":null}

端到端也通过：broker 绑 127.0.0.1:18833 → client connect → subscribe probe/# → broker publish → broker.stats {connections:1, published:3, system:2}。

5. 想确认两件事

1. 这个方向是否符合你们对 routeScoped 语义的预期？另一种等价修法是“先对 request 去掉尾斜杠再判 isBuiltin，内置名一律交还原生解析”（profile 解析器两处缺陷导致所有带依赖的第三方插件无法加载 #9318 提议的 A），对 process/ 也成立；我选 B 是因为它保留路由能力、对任意 request 与 Node 行为一致。如果你们更倾向 A，我可以按 A 重做。
2. 是否需要我补上游测试？建议三条：nodeLookupPaths(parent,'process') === [] 而 'process/' 非空；fixture profile 里放 node_modules/process 后 routePath('process/', …) 返回 native + packageDir 且不抛；e2e 用含 require('process/') 的 CJS 依赖。

我知道 CONTRIBUTING 说目前不接受外部 PR，所以先把补丁放在讨论区。如果需要，我可以按你们格式提供最小补丁或只提供测试；也乐意在你们决定方案后配合调整。

—— dsh-mqtt-tools 作者
dsh-app-boot-fix.patch