Bug: Git 安裝插件未 build（無 dist/）導致 plugin tree 崩潰、backend 無法啟動

[kenchioua]

問題

DeepSeek Harness（0.1.0-rc.7）以 GitHub dependency 安裝插件時，若插件的 build 未執行（沒有產生 dist/），DSH 啟動時 plugin tree boot 失敗，整個 backend 直接退出、無法連線。

重現步驟

1. dsh plugin --profile web add github:adoresever/graph-memory（或任何 exports 指向 dist/ 但沒 build 的 git 插件）
2. 重啟 DSH
3. backend 啟動失敗：

dsh: plugin tree failed to load
failed to import loader entry graph-memory (graph-memory/dsh)
ERR_MODULE_NOT_FOUND: ...\node_modules\graph-memory\dist\dsh.js

根因

graph-memory 的 package.json 宣告 "./dsh": "./dist/dsh.js"、"build": "tsc"，但以 GitHub dependency 安裝時只有 source（dsh.ts/index.ts/src），dist/ 從未產生（build 沒跑）。DSH 載入 graph-memory/dsh 時 ERR_MODULE_NOT_FOUND → 整個 plugin tree 崩潰 → backend 退出。

從 bundles 移除該插件後立即恢復。

建議

1. plugin load failure 應該隔離單一插件，而不是讓整個 backend 無法啟動——一個插件壞，整個 Desktop/backend 掛掉，對使用者影響最大。
2. Git 安裝插件時，應在安裝流程執行 prepare/build 產生 dist（或驗證 exports target 存在）。
3. 缺少 exports target 時應阻止啟用該插件，而非讓它拖垮整個 plugin tree。

環境：Windows 10

[obiwankenobi699]

Thanks for reporting this. Before treating it as a DSH loader bug, could you share the plugin’s package.json

scripts/prepare field, the complete output from dsh plugin --profile web add ..., and the generated profile
pnpm-workspace.yaml including any allowBuilds entry?

DSH currently delegates Git dependency installation to pnpm and reports when a Git plugin’s build script is
blocked. It would be useful to distinguish a blocked install from a successful install that leaves the declared
dist export missing.

If the install succeeds but the plugin tree still crashes because the export target is absent, that sounds like
a clear DSH issue worth fixing.

[kenchioua]

Thanks for the detailed questions. Here are the requested files:

1. Plugin package.json (graph-memory@1.6.0-beta.1, commit dbd72cc)

"scripts": { "build": "tsc", "prepare": "npm run build", "prepack": "npm run build" },
"exports": { ".": "./dist/index.js", "./dsh": "./dist/dsh.js", "./package.json": "./package.json" },
"main": "dist/index.js"

2. Install output

The install was done with pnpm add graph-memory@github:adoresever/graph-memory --ignore-scripts (I bypassed the prepare script because it was failing on Windows). The prepare/build never ran, so dist/ was never generated, yet exports declare ./dsh -> ./dist/dsh.js.

3. Generated pnpm-workspace.yaml (allowBuilds included)

packages:
  - .

nodeLinker: hoisted
autoInstallPeers: false

allowBuilds:
  dsh-better-sidebar@https://codeload.github.com/omdsh-dev/DSH-better-sidebar/tar.gz/498528d2eb96aa9dfec29a94205c73a7ba6ca64b: true
  node-pty: true
  hindsight@https://codeload.github.com/vectorize-io/hindsight/tar.gz/e256a7409b484d66649bcd56e53ddfa37b904ac6: true
  graph-memory@https://codeload.github.com/adoresever/graph-memory/tar.gz/dbd72ccf2ea0a8a2f18a4ed384b55d2161347c80: true

Key finding

The allowBuilds entry for graph-memory was present (last line), yet the install still left dist/ missing because the prepare script was explicitly skipped via --ignore-scripts. This is the "install succeeds but export target is absent" case — the plugin tree crashes on boot with ERR_MODULE_NOT_FOUND for dist/dsh.js, and the whole backend fails to start.

Two distinct Windows failure modes:

1. .sh-based prepare scripts fail (not cross-platform): e.g. hindsight's ./scripts/setup-hooks.sh -> "'.' is not recognized as an internal or external command"
2. --ignore-scripts bypass leaves dist/ missing -> plugin tree crash

Environment: Windows 10, DSH 0.1.0-rc.7 (Desktop v3.1.1)

[kenchioua]

再次驗證（同一問題的又一案例）：dsh-agent-teams（GitHub spec 安裝）同樣缺 lib/index.js 與 lib/client.js → 重啟後 plugin tree boot 失敗 → backend 退出。已永久移除恢復。這確認了「GitHub spec 安裝、exports 指向未 build 的入口檔」是普遍模式，不只 graph-memory——plugin load failure 應隔離單一插件（而非整個 backend 崩潰）對使用者影響最大。相關回報：NanmiCoder/dsh-agent-teams#52

[denial123789]

The follow-up confirms the important distinction: this was not a build that pnpm unexpectedly skipped. --ignore-scripts explicitly bypassed the plugin’s prepare, so the Git source was installed and reconciled into the profile while its declared runtime export was never produced. The later ERR_MODULE_NOT_FOUND is therefore the first boot boundary, while the Web connection failure is only downstream.

A bounded recovery does not require the broken Web profile to boot:

dsh plugin --profile web remove <package-name>
dsh plugin --profile web why <package-name>
dsh --profile web --dump-config
dsh --profile web

After removal, verify both the dependency and dsh.profile.bundles entry are gone. For reinstall, either use a published artifact that already contains every declared exports target, or inspect and permit the exact Git dependency build under allowBuilds, then rerun without --ignore-scripts. On Windows, a POSIX-only prepare script needs a plugin-side cross-platform fix or a prebuilt distribution; bypassing it only converts the visible install failure into a later boot failure.

I documented the rc.7 source path, the three-state router (blocked / bypassed / runtime-broken), recovery, and an artifact release gate here: https://sandbaseai.github.io/deepseek-harness-handbook/git-plugin-missing-dist.html