0.1.7.alpha1 macOS 插件说明报错

[supralune]

升级0.1.7.alpha1后，插件列表的描述报错，如图示：

包元信息错误：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 /Users/wyc/Workspace/DevTools/deepseek-harness/apps/cli/node_modules/@deepseek-ai/dsh-persona/package.json imported from /Users/wyc/.dsh/profiles/web/'

5.6 sol 给出分析如下：

触发链路如下：

1. 插件列表会尝试读取可选资源 en.json，见 package-meta.ts (line 151)。
2. dsh-persona 没有 locale 目录，也没有导出该子路径，见 package.json (line 16)。
3. Node 因此抛出正常的 ERR_PACKAGE_PATH_NOT_EXPORTED。按照现有设计，这属于“可选元信息不存在”，应该被忽略，然后回退到 package.json 中的名称和描述。
4. 但 DSH 的 profile 模块解析器为了修改报错中的 importer 路径，直接重新赋值 error.stack，见 resolver.ts (line 655)。
5. 在你当前的 Node v24.11.0 中，内部 ESM 解析器生成的这个 Error 的 stack 是只读属性，于是第 665 行又抛出了：TypeError: Cannot assign to read only property 'stack'
   这个新 TypeError 覆盖了原始错误码，导致元信息读取器无法把它识别成“可选资源不存在”，最终显示为“包元信息错误”。

[PerryLink]

我把你贴的链路对着源码核了一遍（dsh-v0.1.7-alpha.1，本地 c36a83ff6b）。结构那一半成立，属性那一半我复现不出来，想请你补一个数据点。

成立：这条链路的形状是对的

• packages/boot/app-boot/src/package-meta.ts:151 确实把 ${specifier}/locale/en.json 当可选资源读：

  const englishPath = optionalResourcePath(`${specifier}/locale/en.json`, parentURL)

• package-meta.ts:59-63 的 missingResource() 明确把 ERR_PACKAGE_PATH_NOT_EXPORTED 归入「资源不存在」，:69 于是返回 undefined 正常回退 ⇒ dsh-persona 没有导出这个子路径，本身不该报错。
• 你看到的文案出自 package-meta.ts:169-170 的兜底 catch：

  } catch (error) {
    return { error: `Plugin metadata for ${specifier}: ${String(error)}` }
  }

  ⇒ 在处理解析错误的过程中新抛出的错误，把原始错误挤掉了 —— 这一层判断我认同，也就是"本该被识别为可选资源缺失的错误没走到 missingResource()"。

不成立：error.stack 在 Node 22/24 上是可写的

分析里说 resolver.ts 直接赋值 error.stack 而该属性只读，于是抛 TypeError。我用真实的 ERR_PACKAGE_PATH_NOT_EXPORTED（自建一个不导出子路径的临时包）读属性描述符，两版 Node 上都是 own accessor 且带 setter，裸赋值不抛：

node v22.22.3 → code=ERR_PACKAGE_PATH_NOT_EXPORTED  {own:true, configurable:true, hasGetSet:true}  bareAssignment: OK
node v24.21.0 → code=ERR_PACKAGE_PATH_NOT_EXPORTED  {own:true, configurable:true, hasGetSet:true}  bareAssignment: OK

我又试了另外四种可能的来源 —— structuredClone(error)、跨 worker 边界的 error、Object.freeze(error)、Error.captureStackTrace() —— stack 全部可写（accessor 的 setter 不受 writable/freeze 影响）。要得到 Cannot assign to read only property 'stack'，需要有人显式 Object.defineProperty(err, 'stack', { value })（未带 writable: true）。我在 packages/ 全树搜 defineProperty 与 'stack' 的组合，只命中测试文件。

还有一处对不上：你引的行号是 resolver.ts:655 / :665；在本 tag 上这两处赋值位于 :662-664 与 :691-692，且前置守卫是 if (stack !== undefined)（守的是"读得到"，不是"写得进"）。行号差得较多，你看的可能不是源码而是打包产物、或另一个版本的构建。

请跑一句话，把这件事变成可判定的

在报错的那台机器、同一个 Node 上：

node -e "import('@deepseek-ai/dsh-persona/locale/en.json').catch(e=>{const d=Object.getOwnPropertyDescriptor(e,'stack');console.log(e.code,JSON.stringify({writable:d&&d.writable,hasGetSet:!!(d&&(d.get||d.set))}));try{e.stack='x';console.log('assignment OK')}catch(x){console.log('THREW:',x.message)}})"
node -v

• 出 assignment OK ⇒ 根因不在这一处赋值，要往别的写入点找；
• 出 THREW: Cannot assign to read only property 'stack' ⇒ 你是对的，麻烦把 node -v 连同这行描述符一起贴上来，那这个属性在什么构建里变成只读的就值得单独查。

如果确实在别处，最可能是这两处

生产代码里除 resolver.ts 外还有两处在写 .stack，且都是在改跨域/跨进程过来的 error：

• packages/extensions/cordis-client-runner/src/client/index.ts:155
• packages/session/session-persistence-jsonl/src/migration-verifier.ts:168

不管落在哪一处，修法都不该是「让赋值别抛」

missingResource() 判的是 code，而 code 在整个 message/stack 重写过程中从不被改动。所以更稳的方向是先按 code 分类、再决定要不要重写 error，而不是先改 stack、再指望调用方还能认出原始 code —— 后者的失效模式正是你现在看到的：原始错误码消失，界面只剩一句包元信息错误。

[supralune]

在报错机器上使用 Node v24.11.0、严格 ESM 模式重新测试，结果如下：

plain:
ERR_PACKAGE_PATH_NOT_EXPORTED
{"accessor":true,"configurable":true}
assignment OK

node --import tsx/esm:
ERR_PACKAGE_PATH_NOT_EXPORTED
{"writable":false,"accessor":false,"configurable":true}
THREW: Cannot assign to read only property 'stack'

普通 Node 解析得到的 stack 确实可写；但源码启动使用 node --import tsx/esm，解析错误经过 module hook 链后，stack 会变成 writable:false 的数据属性。

另外，node -e 探针默认运行在 CommonJS 非严格模式中，给只读属性赋值可能静默失败。使用 --input-type=module 或 .mjs 才能可靠复现抛错。

感谢！

[argszero]

I have a machine-measured answer to the request for a data point, and it reconciles both readings. Short version: the read-only stack is real, it is not version-of-Node specific, and it is not tsx specific either — it appears whenever resolution runs through a registered module-hook chain. That is why you cannot reproduce it (no hook registered) and why packages/ contains no defineProperty on stack (the freeze is Node's, not the repo's).

Measured matrix

Same specifier (<pkg>/subpath-not-exported.json), same Node, one variable at a time. The descriptor is read off the real ERR_PACKAGE_PATH_NOT_EXPORTED; the assignment is performed inside an ESM module (strict mode — see the trap below).

runtime	hook chain	own stack	strict 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) — so the trigger is the hook chain itself, not anything tsx does to stacks. tsx is merely one common way to be on that path: on Node 26 the same tsx does not reproduce, while explicitly registering a loader still does. That also explains the environment split in the reports — pnpm dsh is node --import tsx/esm, while an installed launch is plain node with no hooks, which is exactly the reported "source/tsx breaks, installed is fine".

Mechanically the hook chain runs resolution on a separate thread, so the error crosses that boundary and is re-created by Node's error (de)serialization, which installs stack as an own data property without writable: true (it keeps configurable: true). Grepping packages/ for defineProperty+stack was the right instinct, but the property is frozen before dsh's code ever sees the error.

Why the proposed one-liner would answer "not this site" on an affected machine

This is the part I would change, because it can produce a false negative on exactly the machines you want to hear from:

node -e "import('...').catch(e=>{... try{e.stack='x';console.log('assignment OK')}catch(x){...}})"

node -e is a CommonJS script — sloppy mode, and assigning to a non-writable property in sloppy mode silently does nothing instead of throwing. I reproduced that exact contradiction in one run on the affected configuration:

Node 22.20.0 + tsx, reading the descriptor and then assigning:
  code=ERR_PACKAGE_PATH_NOT_EXPORTED own=true data(writable=false) configurable=true
  bare assignment: OK          <-- no throw, because this file is .cjs

So an affected reporter running your snippet would print writable:false and assignment OK together, and the decision rule ("assignment OK ⇒ the root cause is elsewhere") would discard a correct report. dsh's resolver.ts is ESM (packages/boot/app-boot/src/... → .js), hence strict, hence it throws. The reliable discriminator is the descriptor, not the assignment outcome; if you want the assignment in the probe, it must live in an .mjs file (or carry 'use strict'). Suggested shape:

cat > probe.mjs <<'EOF'
try { await import('@deepseek-ai/dsh-persona/locale/en.json') } catch (e) {
  const d = Object.getOwnPropertyDescriptor(e, 'stack')
  let assign = 'OK'; try { e.stack = 'x' } catch (x) { assign = 'THREW: ' + x.message }
  console.log(process.version, e.code, JSON.stringify(d && { own: true, writable: d.writable, accessor: !!(d.get || d.set), configurable: d.configurable }), assign)
}
EOF
node probe.mjs                  # expect accessor / OK
node --import tsx/esm probe.mjs # expect data writable:false / THREW

Line numbers

:655 (function throwWithImporter) and :665 (the assignment) are correct on both tags, and the second rewrite site is :688:

git show dsh-v0.1.7-alpha.1:packages/boot/app-boot/src/profile-resolution/resolver.ts | grep -n 'error.stack = '
# 665:    if (stack !== undefined) error.stack = stack.replace(originalMessage, message)
# 688:    if (stack !== undefined) error.stack = stack.replace(originalMessage, error.message)
git show dsh-v0.1.7-alpha.2:packages/boot/app-boot/src/profile-resolution/resolver.ts | grep -n 'error.stack = '   # same two lines
git show c36a83ff6b:packages/boot/app-boot/src/profile-resolution/resolver.ts | grep -n 'error.stack = '        # your commit: same two lines

Those numbers hold on alpha.1, alpha.2 and on c36a83ff6b itself, so the reporters were reading the source, not a build artifact. The two places you found are additional sites of the same shape; I agree they are reachable, and the CJS one (throwWithoutCjsAnchor) is the more likely second occurrence because MODULE_NOT_FOUND errors also cross the hook boundary.

Where I partly disagree on the fix

I agree with classifying by code before rewriting — but I would not drop the guard, because the observable failure is not that code gets mutated (it never does); it is that a different error object replaces the original: the TypeError propagates out of throwWithImporter at :667's throw error, so the caller never receives the error that carries code, and package-meta.ts:65-72 rethrows anything that is not missingResource() into the catch-all at :169-170. Fixing the rewrite therefore is sufficient for the symptom, and rewriting-first is still the better order — the two are complementary, not alternatives.

Descriptor-aware shape (the get branch matters: Object.defineProperty with value on an accessor descriptor throws Invalid property descriptor, so a single unconditional defineProperty is not enough):

function rewriteStack(error: Error, original: string, message: string): void {
  const stack = error.stack
  if (stack === undefined) return
  const rewritten = stack.replace(original, message)
  const descriptor = Object.getOwnPropertyDescriptor(error, 'stack')
  try {
    if (descriptor?.get !== undefined) error.stack = rewritten
    else if (descriptor !== undefined) Object.defineProperty(error, 'stack', { ...descriptor, value: rewritten })
    else error.stack = rewritten
  } catch {
    // A stack we cannot rewrite is cosmetic. Letting this throw replaces the
    // error and discards its `code`, which is how the plugin page loses the
    // difference between "no locale file" and "the resolver failed".
  }
}

configurable: true is what makes the defineProperty branch work — verified above, the rewrite succeeds on the frozen descriptor. The invariant worth writing down next to it: the error that reaches missingResource() must be the original error, because that predicate keys on code alone (package-meta.ts:59-63) and everything else is reported as a metadata failure.

Worth noting for anyone shipping plugins: this does not only affect built-ins. Every out-of-tree plugin without a locale/en.json export shows the same red error under a source/tsx launch, so a plugin author sees "your package metadata is broken" for a package whose metadata is fine.

[supralune]

Thank you.

I reproduced the exact distinction on the affected machine with Node v24.11.0 and the same package path:

plain Node:
ERR_PACKAGE_PATH_NOT_EXPORTED
{"accessor":true,"configurable":true}
assignment OK

node --import tsx/esm:
ERR_PACKAGE_PATH_NOT_EXPORTED
{"writable":false,"accessor":false,"configurable":true}
THREW: Cannot assign to read only property 'stack'

This confirms that the package's missing optional locale export is only the trigger. The actual repository bug is that throwWithImporter() assumes error.stack is writable after resolution has passed through the module-hook chain. The resulting TypeError replaces the original error carrying ERR_PACKAGE_PATH_NOT_EXPORTED, so the metadata reader can no longer classify the locale resource as optional.

I am marking this as the answer. Thank you for the measured matrix, the strict-mode clarification, and the proposed fix direction.