npx @deepseek-ai/dsh web fails out-of-the-box — @deepseek-ai/dsh@0.1.5-rc.2 ships with incomplete dependencies and stale dist-tags.latest

[kokorolx]

npx @deepseek-ai/dsh web fails out-of-the-box — @deepseek-ai/dsh@0.1.5-rc.2 ships with incomplete dependencies and stale dist-tags.latest

TL;DR

Running npx @deepseek-ai/dsh web on a clean machine (Node 22) crashes during plugin load with two distinct packaging bugs in the published @deepseek-ai/dsh@0.1.5-rc.2 bundle:

1. 18 @deepseek-ai/* packages required at runtime are not declared as dependencies (only as peer deps of internal sub-packages), so a fresh npx install never fetches them — ERR_MODULE_NOT_FOUND on cordis-plugin-group, dsh-session-persistence, dsh-jobs, dsh-bash-local, etc.
2. Even after installing all 18 missing packages, the loader still fails with SyntaxError: The requested module '@deepseek-ai/dsh-session' does not provide an export named 'snapshotJsonValue' — because the latest dist-tag of @deepseek-ai/dsh-session (and many siblings) is stuck at 0.0.1-rc.1 while dsh@0.1.5-rc.2 was built against 0.1.5-rc.2.

Both bugs are reproducible on a brand-new machine in under two minutes. The README's only documented install command (npx @deepseek-ai/dsh web) does not work.

Environment

• macOS 15, Node v22.22.0, npm 10.9.8
• @deepseek-ai/dsh@0.1.5-rc.2 (the version currently on the latest npm dist-tag)
• No prior install of any @deepseek-ai/* package (clean npx cache)

Reproduction

npx --yes @deepseek-ai/dsh web

Failure 1 — missing peer dependencies

node:internal/modules/package_json_reader:314
  throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base), null);
        ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@deepseek-ai/cordis-plugin-group'
  imported from .../node_modules/@deepseek-ai/dsh-app-boot/lib/index.js

@deepseek-ai/dsh-app-boot@0.1.5-rc.2 declares @deepseek-ai/cordis-plugin-group@^1.0.2 as a peerDependency, but the top-level @deepseek-ai/dsh@0.1.5-rc.2 package.json lists it under neither dependencies nor peerDependencies — only cordis-plugin-hmr, cordis-plugin-include, cordis-plugin-loader, cordis-plugin-timer are direct deps. Same pattern for 17 other packages that the loader needs but dsh never asks npm to fetch:

@deepseek-ai/dsh-anonymous-user-id
@deepseek-ai/dsh-attachment
@deepseek-ai/dsh-bash-local
@deepseek-ai/dsh-code-runtime
@deepseek-ai/dsh-compaction
@deepseek-ai/dsh-fs
@deepseek-ai/dsh-jobs
@deepseek-ai/dsh-output-retention
@deepseek-ai/dsh-sandbox
@deepseek-ai/dsh-session-persistence
@deepseek-ai/dsh-session-query
@deepseek-ai/dsh-session-telemetry
@deepseek-ai/dsh-session-title-llm
@deepseek-ai/dsh-settings
@deepseek-ai/dsh-shell
@deepseek-ai/dsh-spill
@deepseek-ai/dsh-subagent-in-process-driver
@deepseek-ai/dsh-util-time

Failure 2 — API mismatch from stale dist-tags.latest

After installing every missing dep above (pinned to 0.1.5-rc.2), the loader still fails:

Error: failed to import loader entry session-log-download
  (@deepseek-ai/dsh-session-log-export):
  The requested module '@deepseek-ai/dsh-session' does not provide
  an export named 'snapshotJsonValue'

Cause: @deepseek-ai/dsh-session's npm dist-tags.latest is 0.0.1-rc.1, which predates the snapshotJsonValue export. The version the rest of dsh@0.1.5-rc.2 was built against (0.1.5-rc.2) only exists on dist-tags.next / dist-tags.alpha. Same staleness for @deepseek-ai/dsh-session-persistence, @deepseek-ai/dsh-jobs, @deepseek-ai/dsh-settings, etc. — npm install <name> resolves to the old latest and silently picks an incompatible API surface.

Working workaround (for anyone stuck)

mkdir dsh-fix && cd dsh-fix
npm init -y >/dev/null
npm install @deepseek-ai/dsh@0.1.5-rc.2
npm install \
    @deepseek-ai/cordis-plugin-group@1.0.2 \
    @deepseek-ai/dsh-anonymous-user-id@0.1.5-rc.2 \
    @deepseek-ai/dsh-attachment@0.1.5-rc.2 \
    @deepseek-ai/dsh-bash-local@0.1.5-rc.2 \
    @deepseek-ai/dsh-code-runtime@0.1.5-rc.2 \
    @deepseek-ai/dsh-compaction@0.1.5-rc.2 \
    @deepseek-ai/dsh-fs@0.1.5-rc.2 \
    @deepseek-ai/dsh-jobs@0.1.5-rc.2 \
    @deepseek-ai/dsh-output-retention@0.1.5-rc.2 \
    @deepseek-ai/dsh-sandbox@0.1.5-rc.2 \
    @deepseek-ai/dsh-session-persistence@0.1.5-rc.2 \
    @deepseek-ai/dsh-session-query@0.1.5-rc.2 \
    @deepseek-ai/dsh-session-telemetry@0.1.5-rc.2 \
    @deepseek-ai/dsh-session-title-llm@0.1.5-rc.2 \
    @deepseek-ai/dsh-settings@0.1.5-rc.2 \
    @deepseek-ai/dsh-shell@0.1.5-rc.2 \
    @deepseek-ai/dsh-spill@0.1.5-rc.2 \
    @deepseek-ai/dsh-subagent-in-process-driver@0.1.5-rc.2 \
    @deepseek-ai/dsh-util-time@0.1.5-rc.2
./node_modules/.bin/dsh web

After that the server starts cleanly on http://127.0.0.1:3080 and the token-URL flow works.

Suggested fix

1. Move all 18 (and likely a few more) @deepseek-ai/* peer-only packages from peerDependencies to dependencies in apps/cli/package.json. They are hard runtime requirements, not "host-provided" peers. (pnpm-lock.yaml already records them as resolvable — npx just doesn't reach the transitive peers.)
2. Republish the dist-tags. Either (a) move every package to its current next/alpha release and re-point latest, or (b) republish 0.1.5-rc.2 across the whole tree so latest matches. Otherwise npm install <pkg>@latest will keep picking 0.0.1-rc.1.
3. The release workflow (scripts/release.sh or equivalent) should either pin explicit versions in apps/cli/package.json or refuse to publish if dist-tags.latest lags behind the CLI's release commit.

Notes

• The README states "Submit feedback or bug reports through GitHub Discussions" — filing here per that.
• A user could not have discovered this from the docs: the only documented install is npx @deepseek-ai/dsh web, which currently fails. The dev path (git clone + pnpm install) is unaffected because pnpm resolves transitives through the workspace.
• Filed from a fresh macOS box; no global dsh install involved.

Thanks for the project — happy to send a PR with the dep-list patch if maintainers are open to it.

[argszero]

Thanks — I spent a while on this one. One half of your report is fully reproducible and much wider than dsh-session; the other half I could not reproduce as written, and I think the two are causally linked.

Failure 2 (stale latest) is real — and it is not one package

Checked against the registry just now (npm view <pkg> dist-tags):

package	latest	next	alpha
@deepseek-ai/dsh	0.1.5-rc.2	0.1.5-rc.2	0.1.6-alpha.2
@deepseek-ai/dsh-session	0.0.1-rc.1	0.1.5-rc.2	0.1.6-alpha.2
@deepseek-ai/dsh-app-boot	0.1.0-rc.6	0.1.5-rc.2	0.1.6-alpha.2
@deepseek-ai/dsh-session-format-v0-to-v1	0.1.3-alpha.2	0.1.5-rc.2	0.1.6-alpha.2

dsh itself is the exception; every sibling still resolves by bare name to a 0.0.1/0.1.0-era build. So the exported-symbol mismatch is not specific to this loader path: anything that resolves a @deepseek-ai/dsh-* dependency by bare name gets an ancient build while dsh is 0.1.5-rc.2. The mechanism is in the release code: distTagForVersion returns next for any version containing -, so a prerelease-only line never advances latest — 0.0.1-rc.1 is simply the last thing that ever landed there. This shape has been reported about a dozen times in this repo. The practical rule for consumers: never resolve a sibling by bare name, mirror dsh's own version or use the next tag.

Failure 1 I could not reproduce as written — and the mechanism matters

In an empty prefix, on npm 11.17.0 / Node 26.5.0:

npm install @deepseek-ai/dsh@0.1.5-rc.2     # 520 packages
dsh --version                              # 0.1.5-rc.2, exit 0

All 18 packages you list are present in that tree. Your observation about the manifests is still correct, and it is stronger than it looks: I walked every installed package.json, and none of the 18 is a dependencies entry of any package in the tree — each is a non-optional peerDependencies entry of an internal package (@deepseek-ai/cordis-plugin-group is a peer of dsh-app-boot and of nothing else). That is deliberate: peers keep one instance per process and let the composition choose the implementation, so the plugin packages are intentionally not dependencies. They appear in my tree only because npm ≥ 7 installs non-optional peers automatically.

Same result on your own npm: I repeated the clean-prefix install with npm@10.9.8 into an empty directory — added 522 packages in 1m, and all 18 packages are present again. So this is not an npm-major difference; the non-optional peers are installed either way.

So ERR_MODULE_NOT_FOUND on your machine means peer installation was disabled in that environment: --legacy-peer-deps, --omit=peer, or a package manager that does not auto-install peers. Worth re-running pinned, which also removes the latest variable:

npx --yes @deepseek-ai/dsh@0.1.5-rc.2 web
npm ls @deepseek-ai/cordis-plugin-group

Why the two halves are one bug

The only reason you had to install those 18 packages by name is that nothing declares them as a dependency. And installing them by name is exactly what hands you 0.0.1-rc.1: the missing-declaration half forces the consumer onto the stale-latest half. Fixing either one alone still leaves the README's only documented install command broken.

Also checked, to rule it out: there is no publish-time manifest drift. apps/cli/package.json at tag dsh-v0.1.5-rc.2 declares exactly the 72 packages that the published dsh@0.1.5-rc.2 declares (0 added, 0 dropped). The fix belongs in the runtime-plugin declaration and in dist-tag promotion, not in the publish step.

Suggested fixes

1. Promote latest as part of the release (or stop treating a prerelease-only line as something latest should serve), so a bare-name resolution never yields a build that predates the API being asked of it.
2. Declare the profile's runtime plugin set as real dependencies (of the profile bundle), or document the peer-only contract loudly — a bare npx must not depend on peer auto-install.
3. Add a release gate that installs the packed tarball into an empty prefix and boots the shipped profile. That is exactly what the README's single documented install command promises, and it would have caught both halves of this report.