latest新版打包导致了cordis版本冲突直接无法打开

[riverai]

Fresh npm i -g @deepseek-ai/dsh@latest assembles a mixed rc.2/rc.3 tree with two cordis copies — dsh web fails: @deepseek-ai/dsh-sandbox-local could not be resolved

Summary

On 2026-09-23, a fresh global install of the latest dist-tag on Windows completes with ~280 ERESOLVE overriding peer dependency warnings and produces an unbootable installation: dsh web prints its URL, then dies with plugin tree failed to load ... @deepseek-ai/dsh-sandbox-local ... could not be resolved.

The evidence below points to a stale latest dist-tag, not a broken release: latest still resolves to 0.1.5-rc.2, whose caret ranges float its subpackages to the newer 0.1.5-rc.3 line, while @deepseek-ai/cordis: ^4.0.2 can now additionally resolve to the recently published 4.0.4. The 0.1.5-rc.3 subpackages peer-pin cordis to exactly 4.0.2, so npm overrides hundreds of peer conflicts and assembles a tree containing two copies of cordis (4.0.2 + 4.0.4) and two generations of cordis-plugin-loader (1.0.3 + 1.0.5). Installing @next (0.1.5-rc.3, which pins cordis 4.0.2 exactly everywhere) yields a clean tree and boots fine.

Environment

OS	Windows (PowerShell 5.x)
Node	v24.16.0 (nvm-windows, C:\Users\River\AppData\Local\nvm\v24.16.0)
Install method	npm global
dsh version	0.1.5-rc.2 (resolved from @latest at install time)

Steps to reproduce

npm uninstall -g @deepseek-ai/dsh   # clean slate
npm install -g @deepseek-ai/dsh@latest
dsh web

Expected: boots the Web UI.
Actual: install completes with a wall of peer-override warnings; dsh web crashes during plugin-tree load.

Full log

Install (the ERESOLVE warning line repeats 280 times; npm printed no conflict details in this mode):

PS C:\Users\River> npm install -g @deepseek-ai/dsh@latest
npm warn ERESOLVE overriding peer dependency
npm warn ERESOLVE overriding peer dependency
npm warn ERESOLVE overriding peer dependency
... (repeated 280 times in total) ...
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead

added 166 packages, removed 121 packages, and changed 397 packages in 1m

First launch, complete output:

PS C:\Users\River> dsh web
dsh web: http://127.0.0.1:3080/?token=1F40LojAj57873bBopwti8AzBG9GA6T3sR_NeDS8M6Y
dsh web: opening the default browser; pass --no-open to disable
file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js:1545
                throw new Error(`${binName}: ${stage}: ${detail}${stack}`, { cause });
                      ^

Error: dsh: plugin tree failed to load: dsh: plugin(s) failed to load: @deepseek-ai/dsh-sandbox-local; Cordis startup failed because these plugin(s) could not be resolved (see the error(s) logged above)
    at boot (file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js:1545:9)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    ... 2 lines matching cause stack trace ...
    at async file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/lib/bin.js:168:23 {
  [cause]: Error: dsh: plugin(s) failed to load: @deepseek-ai/dsh-sandbox-local; Cordis startup failed because these plugin(s) could not be resolved (see the error(s) logged above)
      at assertEntriesLoaded (file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js:1438:9)
      at assertEntriesActivated (file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js:1466:2)
      at boot (file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js:1537:9)
      at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
      at async runProfile (file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/lib/profile-boot-Dk-7KqJc.js:311:14)
      at async runCli (file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/lib/bin.js:146:4)
      at async file:///C:/Users/River/AppData/Local/nvm/v24.16.0/node_modules/@deepseek-ai/dsh/lib/bin.js:168:23
}

Node.js v24.16.0

Analysis

All checks below were performed on 2026-09-23.

1. Dist-tags and ranges (npm registry):

• @deepseek-ai/dsh dist-tags: latest: 0.1.5-rc.2, next: 0.1.5-rc.3, alpha: 0.1.7-alpha.2
• @deepseek-ai/cordis on npm: 4.0.2, 4.0.3, 4.0.4 published; latest: 4.0.4
• dsh@0.1.5-rc.2 declares @deepseek-ai/cordis: ^4.0.2 (loose) and @deepseek-ai/dsh-base: ^0.1.5-rc.2 (floats to 0.1.5-rc.3, since prerelease ordering puts rc.3 inside the range)
• dsh@0.1.5-rc.3 pins @deepseek-ai/cordis: 4.0.2 exactly
• dsh-sandbox-local@0.1.5-rc.3 peer-pins @deepseek-ai/cordis: 4.0.2 exactly (plus dsh-llm/dsh-sandbox/dsh-session at ^0.1.5-rc.3)

So a fresh @latest install now mixes an rc.2 top-level with floated rc.3 subpackages under a cordis range that spans both 4.0.2 and 4.0.4 — exactly the combination the rc.3 pinning was designed to prevent.

2. Reproduced locally (Linux, npm 10): npm i @deepseek-ai/dsh@latest in a scratch dir. npm ls shows the split tree:

└─┬ @deepseek-ai/dsh@0.1.5-rc.2
  ├─┬ @deepseek-ai/cordis-plugin-hmr@1.0.17
  │ └─┬ @deepseek-ai/cordis@4.0.4          <-- 2nd cordis copy (newer line)
  │   └─┬ @deepseek-ai/cordis-plugin-loader@1.0.5
  ├─┬ @deepseek-ai/cordis-plugin-include@1.0.7
  │ └── @deepseek-ai/cordis@4.0.2 deduped
  ├─┬ @deepseek-ai/cordis-plugin-loader@1.0.3          <-- 2nd loader generation
  ├── @deepseek-ai/cordis@4.0.2
  ├─┬ @deepseek-ai/dsh-acp-app@0.1.5-rc.3              <-- rc.3 subpackage floated in
  │ └─┬ ...
  │   └─┬ @deepseek-ai/dsh-sandbox-local@0.1.5-rc.3
  │     └── @deepseek-ai/dsh-sandbox-windows-acl@0.1.5-rc.3

3. Same repro with @next: zero ERESOLVE warnings, a single @deepseek-ai/cordis@4.0.2 throughout the whole tree, and @deepseek-ai/dsh-sandbox-local resolves and imports cleanly (LocalSandboxProvider exported).

4. Why the whole tree dies: dsh-sandbox-local is a base-bundle loader entry (id: sandbox in packages/bundle/base/cordis.patch.yml), so when its entry cannot be resolved, the entire plugin tree fails to load rather than just the sandbox service.

5. User-confirmed fix on the affected Windows machine: switching to @next resolved the boot failure immediately (profiles under ~/.dsh untouched by the reinstall).

Workaround

npm uninstall -g @deepseek-ai/dsh
npm i -g @deepseek-ai/dsh@next
dsh web

@next (0.1.5-rc.3) is self-consistent: every subpackage and peer pin resolves to one cordis version.

Suggested fix

Any of these closes the window for other users hitting @latest during fresh installs:

1. Move the latest dist-tag to 0.1.5-rc.3 (the release that already exists to pin cordis 4.0.2 exactly), or
2. Cut a fresh latest release from a self-consistent tree with exact-pinned subpackage versions (the repo already does this on newer lines: 0.1.7-alpha.2 uses @deepseek-ai/dsh-base: 0.1.7-alpha.2 exact and cordis ~4.0.4), or
3. Republish/patch 0.1.5-rc.2's dependency ranges so they cannot float across subpackage lines (e.g. exact pins), so npm i @deepseek-ai/dsh@latest can never assemble the mixed tree.

Happy to provide the full 280-warning install log or any npm ls output from the broken tree if useful.