[Bug] plugin install reports success but silently disables an unresolved profile bundle

[haihaihaipa]

Summary

When a profile dependency is declared in package.json but missing from node_modules and pnpm-lock.yaml, dsh plugin --profile web install can report success without restoring it. DSH then silently removes the unresolved package from dsh.profile.bundles, leaving the profile in a misleading and inconsistent state.

Environment

• Windows 11
• Node.js v24.13.0
• pnpm v11.0.8
• @deepseek-ai/dsh 0.1.0-rc.6
• Profile: web

Reproduction

1. The profile manifest contains the package in both dependencies and bundles:

{
  "dependencies": {
    "@linxin666/dsh-web-ui-all": "0.1.12"
  },
  "dsh": {
    "profile": {
      "bundles": ["@linxin666/dsh-web-ui-all"]
    }
  }
}

2. The package is absent from node_modules and pnpm-lock.yaml.
3. Run dsh web. It fails with dsh: cannot resolve profile bundle "@linxin666/dsh-web-ui-all".
4. Run dsh plugin --profile web install.
5. The command prints Already up to date and exits successfully, but the package is still missing. DSH also removes it from dsh.profile.bundles while leaving it in dependencies.
6. Explicitly running dsh plugin --profile web add @linxin666/dsh-web-ui-all@0.1.12 repairs the profile.

Expected behavior

After the package-manager command succeeds, DSH should verify that every declared profile dependency and enabled bundle is actually resolvable.

If validation fails, the command should:

• exit with a non-zero status;
• report which bundle is unresolved;
• preserve the original bundle list instead of silently disabling it;
• ideally roll back partial manifest/lockfile changes.

A regression test for a manifest/lockfile/node_modules mismatch would help prevent this from recurring.

Additional note

This appears distinct from discussion #1032, which concerns a missing runtime dependency in a published DSH package. This report concerns profile reconciliation reporting success and mutating the enabled bundle list when the declared dependency is unresolved.

[argszero]

Great report — I reproduced your exact scenario against the current master source and the mechanism is confirmed. Here's the precise chain:

Source confirmation

1. resolveBundleDir throws when the package is unresolvable

packages/boot/app-boot/src/profile.ts:344-355 — for each anchor (dsh installation, then the profile's package.json) it resolves the package directory; if neither anchor finds it, it throws:

${binName}: cannot resolve profile bundle "${packageName}" from the dsh installation or ${profileDir}

2. exportsPatch swallows that throw and returns false

apps/cli/src/plugin.ts:52-62:

function exportsPatch(packageName: string, profileDir: string): boolean {
  let dir: string
  try {
    dir = resolveBundleDir(NAME, packageName, INSTALL_ANCHOR, profileDir)
  } catch {
    return false // pnpm reported success yet the package is unresolvable — treat as plain
  }
  const manifest = readProfileManifest(NAME, dir)
  return manifest.dsh?.bundle?.patch !== undefined
}

3. reconcilePlugins then computes stillBundle = false and removes it from bundles

apps/cli/src/plugin.ts:83-90:

for (const packageName of [...plugins]) {
  const wasDependency = beforeDeps.has(packageName) || dependencySet.has(packageName)
  const stillBundle = dependencySet.has(packageName) && exportsPatch(packageName, profileDir)
  if (wasDependency && !stillBundle) {
    plugins.splice(plugins.indexOf(packageName), 1)
    changed = true
  }
}

In your scenario: the package IS in dependencies (dependencySet.has(pkg) = true) but exportsPatch returns false because it's unresolvable → stillBundle = true && false = false → wasDependency && !stillBundle = true → it gets silently spliced from dsh.profile.bundles, while the dependencies entry is left untouched. The manifest is rewritten (writeProfileManifest at plugin.ts:93) and runPlugin returns the pnpm exit code — which was 0 ("Already up to date"). Hence: success reported, bundle silently disabled.

Why "Already up to date" + silent disable is so insidious

reconcilePlugins runs after every dsh plugin invocation regardless of pnpm's outcome (plugin.ts:114-121), and it's state-based, not diff-based. When pnpm has nothing to do (stale lockfile, missing node_modules), the before/after manifests are identical — yet the reconcile still classifies the unresolvable package as "no longer a bundle" and disables it. The worst part: after this, dsh web stops failing loudly with cannot resolve profile bundle and instead silently boots without the plugin — a much harder failure to diagnose.

The root design tension is in exportsPatch's comment: "unresolvable → treat as plain" conflates two very different situations:

• resolvable but declares no dsh.bundle → legitimately a plain dependency (warn, don't add)
• unresolvable at all → should be an error, not "plain"

Fix suggestions (aligned with your acceptance criteria)

1. Distinguish the two cases in exportsPatch (or in reconcilePlugins): when resolveBundleDir throws and the package was previously an enabled bundle, fail loud (non-zero exit + message naming the unresolved bundle) and preserve the bundle list instead of splicing it.
2. Have runPlugin check result.status !== 0 or the reconcile result and propagate a non-zero exit when a declared/enabled bundle can't be resolved.
3. A regression test for exactly this shape (manifest declares dep+bundle, node_modules/lockfile missing the package, install must not silently disable) — as you noted, matching the session-persistence test conventions would be ideal.

This also deserves a note that a stale pnpm-lock.yaml + present package.json dep is a pnpm-side inconsistency the reconcile currently papers over — but DSH should never silently mutate the user's bundle list in response to it.

Want me to draft a concrete patch against apps/cli/src/plugin.ts (distinguishing the two exportsPatch outcomes) so it's ready if/when upstream opens PRs?

[Electricitysheep]

package.json 声明了但 node_modules/lock 缺失 → install 报成功却静默禁用——这正是第 3 章"依赖解析"坑的又一形态（rc 期 pnpm-lock 与声明不同步）。

排查：install 后核对 pnpm-lock.yaml 是否含该包 + 看插件树是否 active。完整坑位见：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/03-profiles.md

[ylwl1997]

这个「报成功但实际没装上」的静默失败，我们实测目录时也踩过类似坑，常见的静默失败有两类：

1. 包缺 清单—— 只当普通依赖装上、永远不激活，没有任何报错；
2. pnpm 状态不一致——package.json 声明了但 lock/node_modules 缺，下次 install 会「静默清理」。

排查时先 看它到底在不在依赖里，再 看有没有进配置树。这些坑我都整理在排错页了：https://dshbase.com/troubleshooting/