一个由插件引起的dsh web启动失败的问题与解决

[Covidpp]

dsh-issue-plugin-not-built.md

[Covidpp]

第一次没有修复好。。。打个补丁吧
第一遍发现是browser的问题
结果第二次不是，源于我让dsh自己写了一个更新mineru-key的插件，然后一重启就挂彩了，发现需要配置beseURL。。。
被自己蠢哭了。。。
Uploading dsh-repair-log-2026-08-15.md…

[moonquake2004]

Very thorough report — the root cause is clear and matches a failure family we've been tracking. Two notes from our side:

1. This is the same class as dsh-market #18 (monorepo collection repos), which dshmarket already fixed. The marketplace code we read in dsh-market/dsh-market's install.ts has retargetCollections: registry entries pointing at collection repos whose actual plugin lives in a subdirectory get detected, dropped, and re-added via pnpm's #path: selector. Your case (whole-repo copied into node_modules\dsh-browser, real package at packages/browser/bridge-browser) is exactly that shape — so the fix exists on one install path, but every other path (manual install, other marketplaces, older market versions) still hits it. Worth echoing in the marketplace contract discussion (#1846 registry v2: install.spec should be authoritative and point at the subpackage).

2. We shipped an offline check for the unbuilt half of the problem. moonquake2004/dsh-doctor now has P11 (commit ea22628): for every installed bundle it verifies the main target actually exists — a main: lib/index.js with no lib/ (an unbuilt source tree, or the wrong repo-root package) is flagged before boot with the fix hint (run the build, or install the npm-built package; monorepo plugins must install the subpackage). Run dsh-doctor --profile <name> after any marketplace install to catch this pre-boot.

One side note that matches your workaround: tsdown.config.ts failing to load on Node 24 under node_modules ("Stripping types is currently unsupported") is a separate upstream issue worth its own report — your tsc-output fallback is the right local workaround.

[zoahdev]

Accurate writeup - this is the "marketplace copies source without building" failure class, and it is now machine-checkable.

New check: entry-points (dsh-plugin-doctor v1.12.0)

Just shipped a profile check that detects exactly your scenario: it scans every installed plugin's package.json main/exports targets and FAILs when a build artifact is missing:

[fail] entry-points: installed plugin entry points point at missing files
       (source-copy install without build, discussion #1965):
       dsh-browser: lib/index.js. Reinstall from npm or run the plugin's build.

npx dsh-plugin-doctor --profile ~/.dsh/profiles/web

It covers unscoped and scoped packages, main, string exports, and exports["."] maps, and passes when every entry resolves.

The contract fix belongs in the marketplace/installer

• Installers should either install the published npm package or run the plugin's own build (tsc -b && tsdown) before writing cordis.patch.yml - a raw GitHub checkout is not a loadable plugin.
• Plugin authors can close the loop cheaply by committing lib/ (current RC phase) or publishing to npm; our dsh-subscribe registry already marks each entry npm vs github so installers know which path is loadable.

Thanks for the exact repro (commit + patch layer + error) - this one will save a lot of "dsh web won't boot" reports.