[Bug] 第三方插件 dsh-univer-office import 了 dsh-settings 不存在的 settingsNamespace 导出导致整树崩溃

[li299554]

一句话

启动 web profile 时，第三方插件 dsh-univer-office 因 import 了 @deepseek-ai/dsh-settings 不存在的导出 settingsNamespace，导致整棵插件树加载失败、进程崩溃、GUI 端口无法访问。

复现步骤

1. 在 web profile 中安装第三方插件 dsh-univer-office（来源 GitHub/npm，非官方内置）。
2. 启动 dsh web（本机：node --import tsx/esm apps/cli/src/bin.ts web）。
3. 观察启动日志。

实际结果

启动崩溃，报错如下：

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include):
failed to import loader entry univer (dsh-univer-office): The requested module
'@deepseek-ai/dsh-settings' does not provide an export named 'settingsNamespace'
SyntaxError: The requested module '@deepseek-ai/dsh-settings' does not provide an export
named 'settingsNamespace'
    at ... lib/index.js:6857
import { settingsNamespace } from "@deepseek-ai/dsh-settings";

预期结果

要么该插件被官方兼容（若 settingsNamespace 曾在某版本存在），要么平台在加载第三方插件时给出更明确的版本不兼容提示（而不是整个 profile 崩溃、端口完全不可达）。

环境

• 系统：Windows（但此问题与 OS 无关，是 ESM 命名导出不匹配，macOS/Linux 同样会触发）
• DSH 本地仓库版本：@deepseek-ai/dsh-settings@0.1.2-alpha.3
• 当前 settings 包实际导出值：SettingsProvider(default)、SettingsConflictError、redactSecrets；SettingsNamespace 仅为类型导出，非运行时值。

建议（可选）

plugin registry / 市场收录第三方插件时，能否增加"真实加载校验"步骤（至少校验被 import 的命名导出存在），避免收录的插件与当前平台版本不兼容时导致用户整树崩溃？

验收条件

• 官方确认该 issue 归属（settings 包改动 or 插件作者）
• 或给出第三方插件与 settings 版本对齐的方法

[argszero]

Verified against 4e84901e64 (0.1.2-alpha.4) — and the answer to your "若 settingsNamespace 曾在某版本存在" question is yes, it did exist: it was a real runtime export of @deepseek-ai/dsh-settings in 0.1.2-alpha.1 (npm-published), where the seam's register() required a branded value:

// 0.1.2-alpha.1 — packages/settings/settings/src/index.ts:26
export function settingsNamespace(value: string): SettingsNamespace {
  if (!NAMESPACE_PATTERN.test(value)) {
    throw new TypeError(`settings namespace "${value}" must match ${String(NAMESPACE_PATTERN)}`)
  }
  return value as SettingsNamespace
}
register<T>(ns: SettingsNamespace, schema: z<T>, options?: SettingsRegisterOptions<T>): SettingsScope<T>

It was removed by f4e49ccf8f ("refactor(services): move shared values behind service APIs", 2026-08-29) and is already absent in 0.1.2-alpha.2; still absent at alpha.4. So dsh-univer-office was written against the alpha.1 surface, and the pre-release refactor removed the exact export it imports. The removal is intentional under the repo's pre-release policy (rename/repackage freely before the first tagged release): the runtime validator became an internal parseSettingsNamespace plus a compile-time template-literal guard (SettingsNamespaceInput<Value>).

Current export surface (verified at alpha.4):

• runtime values: SettingsProvider (default), SettingsConflictError, redactSecrets
• type-only: SettingsNamespace, SettingsUpdateSource — still exported as types, so import type { SettingsNamespace } keeps working

Migration for the plugin author (about one line):

• Replace ctx.settings.register(settingsNamespace('univer'), schema, ...) with ctx.settings.register('univer', schema, ...). The type-level SettingsNamespaceInput guard and the runtime parseSettingsNamespace (same /^[a-z][a-z0-9-]*$/ pattern, same error message) cover everything the helper did.
• If the plugin used the helper to validate user-supplied names at runtime, it should keep its own check — the pattern is public.
• Pin the peerDependency honestly: >=0.1.2-alpha.2 once updated, or exactly 0.1.2-alpha.1 if it still needs the old API. Note that a caret range on a prerelease (^0.1.2-alpha.1) only matches that same prerelease line, so an explicit range is safer. Nothing today compares a plugin's declared peer range against the installed package at load time — which is exactly why the failure surfaces as a raw ESM named-export SyntaxError instead of a version-alignment hint.

Platform side (your acceptance criterion): the failure path is the vendored Cordis loader (vendor/loader/src/config/entry.ts): an entry import failure is wrapped by updateError('import', ...) (entry.ts:219-220) and rethrown — the first failing entry aborts the whole tree ("plugin tree failed to load: failed to apply loader entry include"), taking the profile and its port down with it. The message does name the plugin entry and the missing export, so diagnosis is possible, but there is no per-entry isolation for third-party plugins and no peer-range comparison. This is the same "one failing fan-out member kills everything" shape as the request-extension prepare path (#5173). A load-time seam would be entry-level isolation for third-party plugin entries (warn + disable that entry, keep the tree alive) plus surfacing the plugin's declared peer range against the installed package. Your "真实加载校验" suggestion is implementable as an install-time preflight — resolving the plugin's imported specifiers against the target package's actual exports before/at dsh plugin add; the existing verify-cordis-config gate is static-only today.