[Bug] 解析拦截器对只读 stack 赋值抛 TypeError，导致全部插件元信息报错（v0.1.7-alpha.2 / tsx 启动）

[GeminiJayson]

本仓库 Issues 已关闭，因此这份 bug 报告发布在 Discussions。下面是完整的环境、根因、最小复现与修复建议。

环境

• DSH 版本：dsh-v0.1.7-alpha.2（active.json 指向的已安装版本）
• 平台：Windows，Node v22.20.0（DSH Desktop 内置 runtime）
• 启动方式：node --import tsx/esm apps/cli/src/bin.ts web --no-open --port 0

现象

设置 → 插件页面里，几乎所有插件的元信息都报错：

包元信息错误：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 C:\...\versions\dsh-v0.1.7-alpha.2\repo\apps\cli\node_modules\@deepseek-ai\dsh-persona\package.json imported from C:\...\dsh-home\profiles\web\'

不止 persona：@deepseek-ai/dsh-skill、@deepseek-ai/dsh-tool-skill 等大批包同样报错（用户反馈"这样的还很多"）。

根因

1. packages/boot/app-boot/src/profile-resolution/resolver.ts 的 throwWithImporter() 在把解析路由到 declarer 后失败时改写诊断：

const stack = error.stack
error.message = message
if (stack !== undefined) error.stack = stack.replace(originalMessage, message)  // ← 罪魁

2. 当宿主用 tsx（--import tsx/esm）启动时，Node 抛出的 ERR_PACKAGE_PATH_NOT_EXPORTED 错误，其 stack 是 own data property 且 writable: false：

{"value":"Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: ...","writable":false,"enumerable":false,"configurable":true}

3. 于是 error.stack = ... 抛 TypeError，而 TypeError 没有 code。
4. packages/boot/app-boot/src/package-meta.ts 的 missingResource() 只识别 error.code，认不出"这个包没有导出 locale"，导致 optionalResourcePath() 不再返回 undefined，readPluginMeta() 把它当作元信息错误上报。
5. 绝大多数包本来就没有 ./locale/en.json 导出（仓库 packages/ 下 578 个包目录里只有 6 个带 locale/en.json），因此凡是缺 locale 的包全部中招。

最小复现

// 用 DSH 自带的 node 执行：node --import tsx/esm repro.ts
import { ModuleLoader } from '@deepseek-ai/cordis-plugin-loader'

const loader = ModuleLoader.fromInternal()!
const base = 'file:///C:/Users/<user>/AppData/Roaming/dsh-desktop/dsh-home/profiles/web/'
try {
  // Node 22 / loader v1；Node 24 v2 为 resolveSync(parentURL, { specifier, attributes })
  loader.resolveSync('@deepseek-ai/dsh-persona/locale/en.json', base, {})
} catch (e: any) {
  console.log(e.code)                                      // ERR_PACKAGE_PATH_NOT_EXPORTED
  console.log(Object.getOwnPropertyDescriptor(e, 'stack'))  // {"writable":false,"configurable":true}
  e.stack = 'x'                                             // TypeError: Cannot assign to read only property 'stack'
}

去掉 --import tsx/esm 后，同一错误的 stack 可写，问题不出现。

建议修复

改写 stack 时不要假定可写：

function rewriteStack(error: Error, original: string, message: string): void {
  const stack = error.stack
  if (stack === undefined) return
  const rewritten = stack.replace(original, message)
  if (rewritten === stack) return
  try {
    error.stack = rewritten
  } catch {
    try {
      Object.defineProperty(error, 'stack', { value: rewritten, writable: true, configurable: true })
    } catch {
      // 保留原 stack 文本即可；message 已标注真实 importer
    }
  }
}

throwWithImporter 与 throwWithoutCjsAnchor 两处都应改用它。

可选加固（防御任何包装层丢失 code）：missingResource() 除了 error.code，也识别 Node 的 is not defined by "exports" / Cannot find module 文本，避免把"没有元数据"误报成错误。

影响面

• 设置页插件清单大面积显示"包元信息错误"，掩盖真实症状，误导排查方向；
• 插件与技能的元信息（标题、描述、图标）全部退化为 fallback；
• 所有依赖 readPluginMeta 的界面都受影响。

修复后验证

• readPluginMeta('@deepseek-ai/dsh-persona' | '@deepseek-ai/dsh-skill' | '@deepseek-ai/dsh-tool-skill') 恢复正常元信息，error 字段消失；
• 拦截路由后的错误保留 code = ERR_PACKAGE_PATH_NOT_EXPORTED，不再被 TypeError 顶替；
• packages/boot/app-boot/tests/package-meta.spec.ts + tests/profile-resolution.spec.ts：303 passed / 1 skipped，0 failed。

[argszero]

Your diagnosis is correct, including the part you emphasized — TypeError has no code, so missingResource() cannot classify it, and the optional-resource path degrades into a metadata error. I reproduced the mechanism on the same Node version you are on (22.20.0) and can add the one variable that explains why this is reported as tsx-specific, plus a caveat for anyone re-running your repro on a newer Node.

The freeze comes from the hook chain, not from tsx

Same Node, same specifier, one variable at a time; descriptor read off the real ERR_PACKAGE_PATH_NOT_EXPORTED, assignment performed from inside an ESM module (strict):

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 and does nothing but return next(specifier, context), yet it reproduces the TypeError on its own. So the property is not made read-only by tsx and not by the Node version: it is made read-only by crossing the module-hook thread boundary, where the error is re-created (same code, same message) and comes back with stack as an own data property that lacks writable: true, while keeping configurable: true. tsx is only one common way to be on that path — which is exactly why your "去掉 --import tsx/esm 后同一错误的 stack 可写" observation is true and still does not make tsx the cause.

That also explains your environment's split: node --import tsx/esm apps/cli/src/bin.ts web is a hook launch, while a plain installed launch registers no hooks.

Two notes for anyone extending your repro:

• Your loader.resolveSync(specifier, base, {}) is the v1 call shape. On Node 24+ the loader is v2 and takes resolveSync(parentURL, { specifier, attributes }); with the v1 shape the v2 loader answers a spurious ERR_INVALID_URL instead of the real resolution error, so the descriptor you print becomes the wrong error's descriptor. Worth pinning node -v next to the output (you already do — that made this diagnosable at all).
• packages/ contains no Object.defineProperty(error, 'stack', …) outside tests, and it does not need to: the property is frozen before dsh's code sees the error. Anyone who greps for a define-property site will come up empty and conclude the analysis is wrong.

On your suggested fix

Your rewriteStack shape is the right one — try the assignment, fall back to defineProperty, and swallow both failures, since a stack we cannot rewrite is cosmetic while a throw replaces the error and discards its code. Two additions:

• Keep the "classify by code first" half as well. code is never mutated by this rewriting; the damage 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's catch-all re-labels it as a metadata error. Fixing the rewrite removes the symptom; not throwing on the rewrite path is what makes missingResource() reachable again.
• If you ever construct the fallback descriptor by spreading the existing one ({ ...descriptor, value: rewritten }), drop get/set first — a descriptor mixing accessor and data fields throws Invalid property descriptor. Your literal { value, writable: true, configurable: true } is fine, and the redefinition succeeds precisely because the frozen property keeps configurable: true.

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

Same bug, two other threads

This is the third report of the identical mechanism: #7528 (Node 24.2.0, same tsx launch, with a library-level repro) and #7518 (macOS, dsh-persona). All three fold into one fix. Also worth adding to your report: this is not limited to built-ins — any out-of-tree plugin without a locale/en.json export shows the same red error under a hook launch, so a plugin author sees "your package metadata is broken" for a package whose metadata is perfectly fine.