dsh plugin add promotes pre-existing bundle-declaring deps into the bundle stack and breaks the next boot with "duplicate loader entry id"

[moonquake2004]

dsh plugin add promotes pre-existing bundle-declaring deps into the bundle stack and breaks the next boot with "duplicate loader entry id"

TL;DR (中文摘要)

dsh plugin --profile web add <pkg> 安装成功后，会把所有声明了 dsh.bundle 的依赖（包括本次命令之前就存在、一直靠 cordis.patch.yml insert 加载的插件）追加进 dsh.profile.bundles。如果用户 patch 里仍保留这些插件的 insert，下一次启动 dsh web 时 cordis loader 会因重复 entry id 直接崩溃：

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): duplicate loader entry id: better-sidebar
TypeError: duplicate loader entry id: better-sidebar
    at EntryGroup.update (cordis-plugin-loader/lib/index.js:81:28)

dsh --profile web --dump-config 检测不到这个问题（它不挂载 loader），只有真实启动才报错。

Environment

• @deepseek-ai/dsh 0.1.0-rc.6 (launched via npx @deepseek-ai/dsh web)
• macOS arm64, Node 22.22.1, pnpm 9.15.9
• Profile: web

Steps to reproduce

1. Profile has out-of-tree plugins installed as file: dependencies and loaded only through the user patch layer (profiles/<name>/cordis.patch.yml inserts) — e.g. dsh-better-sidebar and @liustack/modlens, whose packages do declare "dsh": { "bundle": { "patch": "./cordis.patch.yml" } } but are not in dsh.profile.bundles.
2. Run dsh plugin --profile web add dshmarket (any package triggers it).
3. Restart dsh web → crash: duplicate loader entry id: better-sidebar (and modlens).

Root cause

dsh plugin (the reconcilePlugins step in lib/plugin-*.js) reconciles dsh.profile.bundles against the installed state on every invocation: every dependency that resolves to a package declaring dsh.bundle.patch is appended to the bundle layer list. This is intentional (an update should activate a package that gained the declaration in a newer version), but it also promotes pre-existing dependencies that were never bundle layers and were being loaded via user-patch inserts.

The user's own patch layer (cordis.patch.yml) is not reconciled: its now-redundant insert entries remain, so the same entry id is inserted twice. cordis-plugin-loader's EntryGroup.update throws on duplicate ids at mount time. --dump-config never mounts the loader, so the duplicate is invisible there (verified: dump-config exits 0 with both duplicate rows present in the composed tree) — the failure only appears on a real boot.

Workaround (what fixed it)

Back up and edit profiles/web/cordis.patch.yml: remove the insert entries whose ids are now provided by bundle layers (in my case better-sidebar and modlens); keep only the non-bundle inserts (@local/dsh-emoji-picker, @local/dsh-ui-customizer). Boot then succeeds.

Suggested fixes (any would help)

1. After reconciling bundles, diff the insert ids of the newly-active bundle patches against the user patch; either auto-remove the now-redundant user-patch inserts (keeping a .bak backup) or fail with an actionable message naming the exact file and entries to remove.
2. Add a validation path that mounts the loader (e.g. dsh --profile web --check, or make --dump-config do a mount-only dry run) so duplicate ids surface before the user restarts.
3. Minor UX: when pnpm is missing, dsh plugin prints "pnpm not found on PATH — install pnpm to manage profile plugins" but could suggest concrete commands (corepack enable pnpm / npm i -g pnpm); the dshmarket plugin already provisions pnpm this way.

Note

dshmarket's one-click install also shells out to dsh plugin --profile <name> add, so it inherits this behavior — a user installing anything from the market can hit the same crash if their user patch contains inserts for bundle-declaring packages.

[argszero]

Confirmed — this is a real and distinct bug from #1377 (which I also verified). Here's the exact chain in master, plus why the duplicate-id crash happens.

Source confirmation

1. reconcilePlugins unconditionally promotes every dsh.bundle-declaring dependency

apps/cli/src/plugin.ts:65-71 (first loop):

for (const packageName of dependencies) {
  const isBundle = exportsPatch(packageName, profileDir)
  if (isBundle && !plugins.includes(packageName)) {
    plugins.push(packageName)
    changed = true
  }
  ...
}

This runs on every dsh plugin invocation. Any dependency that resolves to a package declaring dsh.bundle.patch — including pre-existing deps that were never bundle layers and were loaded only via your cordis.patch.yml insert — gets appended to dsh.profile.bundles. The reconcile is intentionally state-based ("an update should activate a package that gained the declaration"), but it cannot know a dependency is being loaded via the user patch layer instead.

2. The duplicate id comes from the user patch insert colliding with the now-active bundle patch

The boot sequence composes: dsh.profile.bundles layers → then the user patch layer (profiles/<name>/cordis.patch.yml, per app-boot/README.md:43 — "applied after every bundle layer"). Your patch still inserts better-sidebar / modlens entries by id, and now those same ids also arrive from the promoted bundle patches → the loader's EntryGroup.update rejects the second occurrence:

vendor/loader/src/config/group.ts:64:

if (seen.has(id)) throw new TypeError(`duplicate loader entry id: ${id}`)

3. Why --dump-config misses it — renderConfigDump composes patches offline without mounting the loader (profile.ts:366 userLayer: false / dump path), so the duplicate-id check never runs. Only a real boot hits EntryGroup.update. Your diagnosis is exactly right.

This vs #1377

• [Bug] plugin install reports success but silently disables an unresolved profile bundle #1377: unresolvable dependency silently removed from bundles (reconcile's second loop splices it).
• dsh plugin add promotes pre-existing bundle-declaring deps into the bundle stack and breaks the next boot with "duplicate loader entry id" #1404: resolvable bundle-declaring dependency silently added to bundles (reconcile's first loop promotes it), clashing with user-patch inserts.

Both stem from the same root: reconcilePlugins is a blind state reconciliation that can't see how a dependency is meant to be loaded (bundle layer vs user patch insert).

Fix suggestions

1. Don't promote deps that the user patch layer already inserts — reconcile against the composed entry-id set (bundle patches + user patch inserts): if a dependency's bundle patch yields ids already present via user-patch inserts, leave it out of bundles (or at least warn).
2. Fail loud on duplicate ids at dsh plugin time — after promoting, compose the bundle patches + user patch and run the same duplicate check the loader does, so the user learns immediately instead of at next boot.
3. Migration path: when the user runs dsh plugin add X, only newly-added deps should be auto-promoted; pre-existing deps should keep their current loading mechanism unless the user explicitly opts in.

The cleanest long-term fix is making the reconcile diff-aware (compare dependency changes since last invocation, like the second loop already does for removal via beforeDeps) rather than scanning the whole installed state every time. This bug deserves a regression test: profile with a bundle-declaring dep loaded only via user-patch insert + dsh plugin add <other> → assert the dep is NOT promoted and boot stays clean.

Want me to draft the diff-aware reconcile patch against apps/cli/src/plugin.ts (covers both #1377 and #1404) so it's ready if/when upstream opens PRs?

[moonquake2004]

Thanks for the thorough verification — the source-level walkthrough (the promotion loop in apps/cli/src/plugin.ts:65-71, the duplicate-id check in vendor/loader/src/config/group.ts:64, and the offline dump path) matches exactly what we hit, and the comparison with #1377 is a good clarification: same blind state-reconciliation root, opposite directions (unresolvable → silently dropped; resolvable bundle-declaring → silently promoted).

I agree with your direction:

• The minimal correct guard is not promoting a dependency whose bundle-patch ids already come from the user patch layer (or at least warning loudly);
• The cleanest long-term fix is the diff-aware reconcile you describe — only newly added/changed deps drive the bundle list, mirroring how the second loop already uses beforeDeps.

And yes — if you draft the patch, I would be glad to test it. I still have the exact repro (profile with a bundle-declaring file: dep loaded only via a cordis.patch.yml insert + dsh plugin add <other> → next boot crashes), which can double as the regression test you suggested. I also wrote a tiny pre-boot collision checker (compares bundle-patch insert ids against the user patch) as a stopgap — happy to share it and fold it into the fix as a --check mode if useful.

Since issues are disabled upstream, a PR is the right vehicle — happy to help however that lands.