@deepseek-ai/dsh-tools@0.0.1-rc.1 (npm latest) is not installable: peer @deepseek-ai/dsh-type-meta is unpublished

[lxj808624]

Summary

@deepseek-ai/dsh-tools@0.0.1-rc.1 — the version tagged latest on npm — cannot be installed by any external plugin: pnpm fails with a 404 because its peer graph references @deepseek-ai/dsh-type-meta, which is not published to the npm registry.

We hit this while building an external plugin (dsh-tool-git). Any project that lists @deepseek-ai/dsh-tools in its dependencies (the documented path for plugin authors) fails to install:

[ERR_PNPM_FETCH_404] GET https://registry.npmjs.org/@deepseek-ai%2Fdsh-type-meta: Not Found - 404

Root cause

The chain (verified with npm view ... --json on the 0.0.1-rc.1 line):

• @deepseek-ai/dsh-tools@0.0.1-rc.1 has peerDependencies including @deepseek-ai/dsh-session@^0.0.1-rc.1
• @deepseek-ai/dsh-session@0.0.1-rc.1 has peerDependencies including @deepseek-ai/dsh-type-meta@^0.0.1-rc.1
• @deepseek-ai/dsh-type-meta is not on npm (404 on both npmjs and mirrors), so pnpm's peer-manifest resolution fails hard — even with auto-install-peers=false, because pnpm still fetches peer manifests while resolving the graph.

Impact

• External plugin developers cannot install the latest-tagged dsh-tools at all.
• dsh-base depends on dsh-tools@^0.0.1-rc.1, which resolves to 0.0.1-rc.5 (highest matching), so the shipped runtime works — but anyone pinning the latest tag or 0.0.1-rc.1 explicitly is broken.

Workaround (for plugin authors)

Pin @deepseek-ai/dsh-tools to 0.0.1-rc.5 (or 0.1.0-rc.6 from the next tag) — both install cleanly and are API-compatible for the stable surface (defineTool, ctx.tools.*, tools/pre-execute, etc.).

Suggested fix

Either publish @deepseek-ai/dsh-type-meta (and verify the whole 0.0.1-rc.1 peer closure is on npm), or fix @deepseek-ai/dsh-session@0.0.1-rc.1's peerDependencies and re-tag/re-publish dsh-tools. A dsh-tools latest tag that points at an installable version would unblock every external plugin author.

(Reported while developing https://github.com/lxj808624/dsh-tool-git, which uses the rc.5 workaround.)

[PerryLink]

Confirmed today — the chain you identified is still live, and I can add one measurement that changes the diagnosis slightly.

Current registry state (2026-09-20)

$ npm view @deepseek-ai/dsh-tools dist-tags --json
{ "latest": "0.0.1-rc.1", "next": "0.1.5-rc.2", "alpha": "0.1.6-alpha.2" }

latest still points at 0.0.1-rc.1, and @deepseek-ai/dsh-type-meta is still absent:

$ npm view @deepseek-ai/dsh-type-meta
npm error 404 Not Found - GET https://registry.npmjs.org/@deepseek-ai%2fdsh-type-meta

So pnpm add @deepseek-ai/dsh-tools with no version specifier still fails hard today, not just the explicit @0.0.1-rc.1 pin.

Where npm and pnpm actually diverge

You reported that only pnpm fails. npm does install the same specifier:

$ npm install @deepseek-ai/dsh-tools@0.0.1-rc.1
added 17 packages in 5s          # exit 0

But the reason is not that npm is more permissive. It is which version of the peer each one lands on. Inspecting the resulting lockfile, npm resolved @deepseek-ai/dsh-session@^0.0.1-rc.1 to 0.0.1-rc.5, not rc.1:

node_modules/@deepseek-ai/dsh-session => 0.0.1-rc.5
node_modules/@deepseek-ai/dsh-type-meta   (absent)

And rc.5's peer set no longer contains dsh-type-meta — it was replaced by dsh-typert-protocol:

$ npm view @deepseek-ai/dsh-session@0.0.1-rc.1 peerDependencies
{ ... "@deepseek-ai/dsh-type-meta": "^0.0.1-rc.1" ... }     <- rc.1 requires it

$ npm view @deepseek-ai/dsh-session@0.0.1-rc.5 peerDependencies
{ ... "@deepseek-ai/dsh-typert-protocol": "^0.0.1-rc.5" ... }   <- rc.5 does not

The decisive check: pin the broken version explicitly and npm behaves exactly like pnpm.

$ npm install @deepseek-ai/dsh-session@0.0.1-rc.1
npm error code E404
npm error 404 Not Found - GET https://registry.npmjs.org/@deepseek-ai%2fdsh-type-meta
# exit 1

So: pnpm lands ^0.0.1-rc.1 on rc.1 while resolving the peer graph and must fetch that manifest, which 404s. npm lands the same range on rc.5 and never needs the missing manifest. npm is not resolving the failure — it is picking a different version that does not have the problem.

What works today (all measured with pnpm 11.21.0)

pnpm add @deepseek-ai/dsh-tools@0.0.1-rc.5     # exit 0
pnpm add @deepseek-ai/dsh-tools@0.1.0-rc.6     # exit 0
pnpm add @deepseek-ai/dsh-tools@next           # exit 0
pnpm add @deepseek-ai/dsh-tools                # ERR_PNPM_FETCH_404, exit 1
pnpm add @deepseek-ai/dsh-tools@0.0.1-rc.1     # ERR_PNPM_FETCH_404, exit 1

next resolves to 0.1.5-rc.2 as of today, but that tag will move — pin an explicit version if your build depends on it.

Two things I tried that do not help, so you do not spend time on them: adding a pnpm.overrides entry forcing @deepseek-ai/dsh-session to 0.0.1-rc.5, and a pnpm.packageExtensions block marking dsh-type-meta as an optional peer of dsh-session@0.0.1-rc.1. Both still end in ERR_PNPM_FETCH_404. If you need dsh-tools in a pnpm workspace, the working options are to select a version whose peer closure exists, or to install that one dependency with npm.

Your read of dsh-base is also correct in the 0.0.1-rc.x line: dsh-base@0.0.1-rc.1 depends on dsh-tools@^0.0.1-rc.1, which resolves upward to rc.5 — that is why that line's shipped runtime was fine. Later lines pin dsh-tools in lockstep with their own version (dsh-base@0.1.5-rc.2 → dsh-tools@^0.1.5-rc.2), so this defect only bites a consumer that follows the latest tag (or pins 0.0.1-rc.1) directly.

The remaining defect is on the publish side — a latest tag pointing at a version whose peer closure does not exist on the registry. A smoke step that installs every package at its latest tag in a clean directory would have caught this and would catch it again.

If this resolves it for you, marking it as the answer would help the next person who hits the same 404.