内置插件列表全部报「包元信息错误」：resolution 诊断改写只读 stack 抛 TypeError（源码启动 + tsx）

[Kidimos]

Summary

用源码启动的 DSH（pnpm dsh web = node --import tsx/esm apps/cli/src/bin.ts）打开 设置 → 内置插件 时，每一个没有 locale/en.json 的包都显示红色错误：

包元信息错误: Plugin metadata for @deepseek-ai/dsh-persona: TypeError: Cannot assign to read only property 'stack' of object 'Error: Package subpath './locale/en.json' is not defined by "exports" in <checkout>/apps/cli/node_modules/@deepseek-ai/dsh-persona/package.json imported from <home>/.dsh/profiles/web/'

persona、agent-instructions、tool-bash、tool-pwsh … 全部命中（specifier 不同、错误形式相同）。安装版 dsh（非 tsx 启动）不会出现，所以看起来像"所有内置插件都坏了"，实际上插件本身都正常（都显示"已启用"）。

问题不在插件，而在 profile resolution 的一条诊断改写路径：它假设 error.stack 可写，而源码启动时 Node 会把解析错误以只读 stack 数据属性的形式返回，改写因此抛 TypeError，并且该 TypeError 顶替了真正的 ERR_PACKAGE_PATH_NOT_EXPORTED。

Environment

项	值
仓库 / 版本	deepseek-harness master 00102833df（release 0.1.7-alpha.2）
启动方式	pnpm dsh web（package.json 的 scripts.dsh = node --import tsx/esm apps/cli/src/bin.ts）
Node	v24.2.0（V8 13.6.233.10-node.17）
tsx	4.22.4
OS	macOS（darwin arm64）
Profile	web，位于 <home>/.dsh/profiles/web；解析由 runtime resolution 路由到安装目录的 apps/cli/node_modules

Reproduction

1. 库级最小复现（不需要 GUI）

node repro.mjs                  # 普通启动
node --import tsx/esm repro.mjs  # tsx 启动

// repro.mjs
import { createRequire } from 'node:module'
const require = createRequire(process.cwd() + '/packages/boot/app-boot/src/package-meta.ts')
const addon = require('node-addon-require-builtin')
const esm = addon.requireBuiltin('internal/modules/esm/loader').getOrInitializeCascadedLoader()
const parent = 'file:///<home>/.dsh/profiles/web/'
try {
  esm.resolveSync('@deepseek-ai/dsh-persona/locale/en.json', parent, {})
} catch (error) {
  console.log(Object.getOwnPropertyDescriptor(error, 'stack'))
}

同一个 Node、同一个解析，只是启动方式不同：

启动方式	own stack 描述符	error.stack = 'x'
node repro.mjs	{ get: [Function], set: [Function], configurable: true }	成功
node --import tsx/esm repro.mjs	{ value: 'Error [ERR_PACKAGE_PATH_NOT_EXPORTED] …', writable: false, enumerable: false, configurable: true }	抛出 TypeError

2. 端到端（与 GUI 完全同一条路径）

安装 runtime interception 后直接调用 readPluginMeta：

// 已安装 installRuntimeInterception(webProfile 的 runtime resolution)
readPluginMeta('@deepseek-ai/dsh-persona', 'file:///<home>/.dsh/profiles/web/')

返回：

{ "error": "Plugin metadata for @deepseek-ai/dsh-persona: TypeError: Cannot assign to read only property 'stack' of object 'Error: Package subpath './locale/en.json' is not defined by \"exports\" in <checkout>/apps/cli/node_modules/@deepseek-ai/dsh-persona/package.json imported from <home>/.dsh/profiles/web/'" }

3. GUI

源码启动 pnpm dsh web → 设置 → 内置插件：每个无 locale/ 目录的包都显示上述错误。

Current behavior

• 内置插件列表里所有没有 locale/en.json 的包都出现红色"包元信息错误"，即便这些包完全正常（显示"已启用"）。
• 报错文本是 TypeError，而不是真正的解析错误；Package subpath './locale/en.json' is not defined by "exports" 这句只作为 TypeError 的被引用对象出现。
• 同样的机制会影响任何经 runtime interception 的解析失败诊断（ESM 的 throwWithImporter、CommonJS 的 throwWithoutCjsAnchor）。

Root cause

1. readPluginMeta()（packages/boot/app-boot/src/package-meta.ts:148）先解析 <specifier>/locale/en.json；这些包没有 exports["./locale/*"]，Node 抛 ERR_PACKAGE_PATH_NOT_EXPORTED。
2. 该解析经过了 runtime interception。由于 profile 的 importer 在拦截作用域内，请求被路由到安装目录的 declarer，解析失败后由 throwWithImporter()（packages/boot/app-boot/src/profile-resolution/resolver.ts:655）把诊断里的内部 anchor 还原成真实 importer，其中包含 error.stack = stack.replace(...)（第 665 行）。
3. 源码启动时这条赋值会抛：tsx 在 Node 24.2 上使用 module.register()（异步 loader worker）。解析错误从 worker 回主线程要经过 node:internal/modules/esm/hooks 第 635 行 throw deserializeError(body.serialized)，而 deserializeError（node:internal/error_serdes，第 164 行）用 ObjectCreate(ctor.prototype, properties) 还原错误，stack 因此是 writable: false 的数据属性，赋值在严格模式下抛 TypeError: Cannot assign to read only property 'stack' …。（普通 Node 下同一个错误是 V8 的 stack 访问器，赋值正常。）
4. optionalResourcePath()（packages/boot/app-boot/src/package-meta.ts:65）通过 missingResource()（第 59 行）按 error.code 判断"子路径不存在"；TypeError 没有 code，于是向外冒泡。
5. readPluginMeta() 的兜底 catch（第 169-171 行）把它渲染成 { error: 'Plugin metadata for …' }，GUI 显示为"包元信息错误"。

即：一个纯诊断性的 stack 改写，把"无 locale 子路径 = 无元信息、回退 package.json"的正常路径，变成了全列表报错。

Expected behavior

• 包没有 locale/en.json 时，readPluginMeta 应视为"无 locale 资源"，回退到 package.json 的 name/description（或者返回 undefined），不应产生错误卡片——这正是 optionalResourcePath + missingResource 现有的设计。
• 即使 stack 改写无法完成，也必须保留原始解析错误（code、message），不能用一个 TypeError 顶替它；code 是调用方判断"资源缺失"的唯一依据。

Suggested fix（供参考，未提交 PR）

packages/boot/app-boot/src/profile-resolution/resolver.ts：把两处 error.stack = … 换成对描述符友好的写法，例如

/**
 * Replace an error's stack text.
 *
 * Node returns errors raised in the ESM loader host through `deserializeError`
 * (`node:internal/error_serdes`), which publishes `stack` as a non-writable
 * data property, so assignment throws for what is otherwise a diagnostic rewrite.
 */
function replaceStack(error: Error, stack: string): void {
  try {
    error.stack = stack
  } catch {
    // A deserialized loader error carries a non-writable `stack` data property.
    Object.defineProperty(error, 'stack', { value: stack, writable: true, enumerable: false, configurable: true })
  }
}

调用点：throwWithImporter（665 行）与 throwWithoutCjsAnchor（688 行），后者有同一处假设。

回归用例可以直接构造"只读 stack"的解析错误（例如 module.registerHooks() 抛出一个 stack 为 writable: false 的 ERR_MODULE_NOT_FOUND），断言抛出的仍是原错误、且 message/stack 已还原成真实 importer。我在本地按这个方案验证过：修复前用例复现截图里的 TypeError，修复后 profile-resolution.spec.ts 225/225 通过，app-boot 全包 5455 passed。

顺带发现（本次未处理）

vendor/cordis 里也有同样的"直接给 error.stack 赋值"假设：vendor/cordis/src/utils.ts:248,263 与 vendor/cordis/src/reflect.ts:76。因为 vendor 修改要走 同步流程，这里只做记录：任何被 composeError 包裹的插件调用，如果抛出的是 deserialized 错误，同样会被 TypeError 顶替。

Impact

• 所有源码启动（开发/自建）的 DSH：内置插件页对每个无 locale 的包报错；"添加插件"、插件管理页依赖同一元信息读取器，展示文本不可信。
• 安装版 dsh 不受影响（没有 tsx 的异步 loader hook 链），因此容易被误判为"某些插件包坏了"。
• 触发条件与 profile 是否自建无关：任何 importer 落在 profile/linked root 内、且目标子路径未导出，都会走到这条路径。

[Kidimos]

[argszero]

Your measurement is right, and it matches mine — I want to add the one variable that explains the whole family, because the framing "tsx 启动时" is one step short of the cause, and it changes who is affected.

The trigger is the hook chain, not tsx

I ran the same experiment as your §1, one variable at a time, on the same Node. Reading the descriptor of the real ERR_PACKAGE_PATH_NOT_EXPORTED, assigning from inside an ESM module:

runtime	hook chain	own stack	assignment
Node 22.20.0	none	accessor (get/set)	OK
Node 22.20.0	tsx (--import tsx/esm)	data, writable:false, configurable:true	TypeError: Cannot assign to read only property 'stack'
Node 22.20.0	a no-op loader (--experimental-loader)	data, writable:false	same TypeError
Node 22.20.0	a no-op loader (--import + module.register())	data, writable:false	same TypeError
Node 24.2.0	none	accessor	OK
Node 24.2.0	tsx	data, writable:false	same TypeError
Node 26.5.0	none	accessor	OK
Node 26.5.0	tsx	accessor	OK
Node 26.5.0	a no-op loader (register())	data, writable:false	same TypeError

The no-op loader is one line — export const resolve = async (specifier, context, next) => next(specifier, context) — and it reproduces the TypeError on its own. So the property is not frozen by tsx and not by the Node version: it is frozen by crossing the module-hook thread boundary, where the error is re-created by Node's error (de)serialization and gets stack installed as an own data property without writable: true (it keeps configurable: true).

That predicts your "安装版不会出现" datapoint exactly: pnpm dsh is node --import tsx/esm, an installed launch is plain node with no hooks registered. It also predicts the Node-26 oddity in the table above — tsx on 26 uses the newer in-thread hooks, so the same tsx stops reproducing while an explicitly registered loader still does.

One corollary worth putting in the report: packages/ needs no defineProperty for this to happen. Grepping for it and finding only tests is a correct observation with the wrong conclusion — the freeze happens before dsh's code ever sees the error.

Cross-check against the other threads

PerryLink argued in #7518 that on Node 22.22.3 / 24.21.0 the stack of a real ERR_PACKAGE_PATH_NOT_EXPORTED is an own accessor with a setter, so bare assignment cannot throw — and he is also right. Both readings are the same measurement under different configurations; the missing column in both is the hook chain. He also flagged resolver.ts:655/:665 as not matching the tag (he read :662-664/:691-692): I re-checked with git show <tag>:packages/boot/app-boot/src/profile-resolution/resolver.ts | grep -n 'error.stack = ' and both alpha.1 and alpha.2 carry the assignments at :665 and :688, so the reporters' numbers are the source ones.

The same root cause is filed separately as #7533 (Windows, Node 22.20.0, same tsx launch) — that is the third instance, and the fix below covers all of them.

On your proposed fix

Your rewriteStack shape is right, and the try/defineProperty order is the correct one. Two additions:

• Keep the classify-by-code idea in front of the rewrite. Not because code is ever mutated — it never is; the whole message/stack rewriting leaves it alone — but because the failure mode is that a different error object replaces the original: the TypeError propagates out of throwWithImporter, so the caller never receives the error carrying code, and package-meta.ts catch-all turns it into a metadata failure. Both halves are needed in the sense that either one alone removes the symptom; rewriting-first with a guard is the cheaper one.
• If you ever build the fallback descriptor by spreading ({ ...descriptor, value: rewritten }), you must drop get/set first — mixing accessor and data fields in one descriptor throws Invalid property descriptor. Your literal { value, writable: true, configurable: true } avoids that, and redefinition works precisely because the property keeps configurable: true (verified on the frozen descriptor above).

The invariant worth writing next to the helper: the error that reaches missingResource() must be the original error — that predicate keys on code alone, so anything that replaces the error is indistinguishable from a genuine metadata failure.

Who this hits

Worth adding to your report: it is not only ~578 built-in package directories. Out-of-tree plugins have the same shape — any third-party plugin without a locale/en.json export shows the identical red "包元信息错误" under a source/tsx launch, so a plugin author sees "your package metadata is broken" for a package whose metadata is fine. That turns a cosmetic resolution-diagnostic rewrite into a contributor-visible bug.