@deepseek-ai/dsh is uninstallable on both latest and next — rc.3 wave shipped dsh-web-app requiring a dsh-client-ui-sidebar-documentpreview@0.1.5-rc.3 leaf that was never published

[xrayfinding]

TL;DR

As of 2026-09-22T06:28Z, the README's documented install command fails on a clean machine for both promoted dist-tags:

dist-tag	version	state
latest	0.1.5-rc.2	❌ ETARGET (broken retroactively at 05:53Z today)
next	0.1.5-rc.3	❌ ETARGET (broken since it was tagged)
alpha	0.1.7-alpha.1	✅ installs and runs

All failures are the same missing leaf:

npm error notarget No matching version found for
@deepseek-ai/dsh-client-ui-sidebar-documentpreview@^0.1.5-rc.3.

Two independent defects, both in the publish pipeline (not in the code):

1. The 0.1.5-rc.3 wave published its parents but never published that leaf. dsh-web-app@0.1.5-rc.3 was published declaring @deepseek-ai/dsh-client-ui-sidebar-documentpreview@^0.1.5-rc.3, which does not exist on the registry — and still does not.
2. Carets on intra-monorepo prerelease deps make old releases break retroactively. dsh@0.1.5-rc.2 (the latest tag) declares @deepseek-ai/dsh-web-app@^0.1.5-rc.2; that range floats to today's 0.1.5-rc.3, which requires the missing leaf. So latest became uninstallable two days after it was published, with zero republishes.

A third, latent issue: the wave itself is racy — parents are published before leaves (observed live: parent at 06:21:56Z, leaf at 06:22:16Z), and a dist-tag was promoted while its own tarball still 404'd.

Recurring, not new: #2991, #3461, #5969, #6168, #7135, #7362 are the same class of report. #6168 is literally the same ETARGET on 0.1.5-rc.1.

Environment

• Windows 11, node v24.14.0, npm 11.9.0, clean npm cache, no prior @deepseek-ai/* install
• Reproduced identically on macOS 15 / Node 22 / npm 10.9.8 (per `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 #7135)

Reproduction

npx --yes @deepseek-ai/dsh web

Need to install the following packages:
@deepseek-ai/dsh@0.1.5-rc.2
Ok to proceed? (y) y
npm error code ETARGET
npm error notarget No matching version found for @deepseek-ai/dsh-client-ui-sidebar-documentpreview@^0.1.5-rc.3.
npm error notarget In most cases you or one of your dependencies are requesting
npm error notarget a package version that doesn't exist.

Same result for @deepseek-ai/dsh@latest, @deepseek-ai/dsh@next, and @deepseek-ai/dsh@0.1.5-rc.2 directly.

Evidence (registry.npmjs.org, 2026-09-22T06:05–06:28Z)

1. dist-tags and published versions of the missing leaf

@deepseek-ai/dsh
  latest = 0.1.5-rc.2   next = 0.1.5-rc.3   alpha = 0.1.7-alpha.1

@deepseek-ai/dsh-client-ui-sidebar-documentpreview
  latest = 0.1.5-alpha.2   next = 0.1.5-rc.2   alpha = 0.1.7-alpha.1
  versions = 0.1.5-alpha.2, 0.1.5-rc.1, 0.1.5-rc.2, 0.1.6-alpha.1, 0.1.6-alpha.2, 0.1.7-alpha.1
  → 0.1.5-rc.3 was never published (the leaf skipped the entire rc.3 line)

2. The rc.3 wave: parents published, leaf skipped

From the time field of each package:

05:41:09Z  dsh-app-boot@0.1.5-rc.3
05:48:17Z  dsh-base@0.1.5-rc.3
05:53:17Z  dsh-web-app@0.1.5-rc.3        -> requires dsh-client-ui-sidebar-documentpreview@^0.1.5-rc.3
05:55:20Z  dsh@0.1.5-rc.3
05:55:48Z  dsh-client-web@0.1.5-rc.3
   —       dsh-client-ui-sidebar-documentpreview@0.1.5-rc.3   ← never published

3. Why the "stable" latest tag broke retroactively

$ npm view "@deepseek-ai/dsh-web-app@^0.1.5-rc.2" version
@deepseek-ai/dsh-web-app@0.1.5-rc.2 '0.1.5-rc.2'
@deepseek-ai/dsh-web-app@0.1.5-rc.3 '0.1.5-rc.3'      # ← npm picks this one

$ npm view @deepseek-ai/dsh-web-app@0.1.5-rc.3 dependencies
  "@deepseek-ai/dsh-client-ui-sidebar-documentpreview": "^0.1.5-rc.3"

^0.1.5-rc.2 accepts 0.1.5-rc.3 (same [0.1.5] tuple, so prerelease matching applies), and 0.1.5-rc.3 of the web app needs a leaf that does not exist. Result: dsh@0.1.5-rc.2 — published 2026-09-10, untouched since — became uninstallable at 05:53Z today the instant the new wave landed. Any user of latest, any CI, and any npm mirror that lags the registry sees this.

4. Latent: each wave is racy, and tags are promoted before artifacts exist

Observed live on the alpha wave (same publish job):

06:21:56Z  dsh-web-app@0.1.7-alpha.1                    -> requires documentpreview@^0.1.7-alpha.1
06:22:16Z  dsh-client-ui-sidebar-documentpreview@0.1.7-alpha.1   (+20s)

For those 20 seconds, every install of that wave dies with the same ETARGET. Additionally, at 06:27:13Z the alpha tag already pointed at 0.1.7-alpha.1 while its own tarball was not yet fetchable:

$ curl -o /dev/null -w '%{http_code}' https://registry.npmjs.org/@deepseek-ai/dsh/-/dsh-0.1.7-alpha.1.tgz
404

(npm install @deepseek-ai/dsh@alpha succeeded a moment later — 512 packages, dsh --version → 0.1.7-alpha.1 — so this window closed, but it demonstrates tag-before-artifact ordering.)

Impact

• @deepseek-ai/dsh is at ~353,089 downloads/week; npx @deepseek-ai/dsh web is the only install command the README documents, and it fails out of the box right now.
• next currently points at a tree that can never resolve; latest points at a tree that broke retroactively — so there is no "known good" stable entry point to recommend.
• Also blocks offline/lagging mirrors and phones-home style installers, which cannot be fixed by "just retry later" (see the registry-mirror discussion in [Bug] dsh 0.1.0-rc.8 is not installable from npm: missing dsh-agent-loop@^0.1.0-rc.8 #3461).

Suggested fixes (publish pipeline, in priority order)

1. Publish the wave atomically, leaves first. Topologically sort (leaf plugin packages → app bundles → CLI) and only promote dist-tags once the entire wave is resolvable.
2. Gate every dist-tag promotion on a resolvability smoke test. From a clean directory: npm install --dry-run --no-audit @deepseek-ai/dsh@<tag>; the ETARGET shows up in under 30 s. Run it for latest / next / alpha before/after npm dist-tag add. A dsh-shipped install-doctor (Community tool: DeepSeek Harness Install Doctor #3469) would be a good home for this check on the user side, but it must run in CI on the publish side to be preventive.
3. Roll back a broken tag instead of leaving it promoted. If a wave fails, point the tags at the last known-good versions (npm dist-tag add @deepseek-ai/dsh@<prev> next) and npm deprecate the unresolvable version with a pointer. Today next has been pointing at an unresolvable tree since 05:55Z.
4. Stop using prerelease carets for intra-monorepo deps. ^0.1.5-rc.2 means "any 0.1.5 prerelease ≥ rc.2", so every new wave retroactively invalidates every earlier release of the same line. Either pin exactly (0.1.5-rc.3) or let pnpm publish rewrite workspace:* to exact versions. Exact pins also make the release self-consistent when a wave is partially published.
5. Publish the tarball before promoting the tag (the 06:27Z 404 on dsh-0.1.7-alpha.1.tgz while alpha already pointed at it).
6. Give the leaf packages a publish check of their own — a package that is a dependency of a released parent but has no matching version for the wave is exactly what a "wave completeness" assertion would catch.

Workaround for users right now

npx @deepseek-ai/dsh@alpha web        # currently 0.1.7-alpha.1 — verified installing and running
# or pin:
npm i -g @deepseek-ai/dsh@0.1.6-alpha.2

Verified on this machine: npm install @deepseek-ai/dsh@alpha → added 512 packages, ./node_modules/.bin/dsh --version → 0.1.7-alpha.1, dsh web --help OK. latest / next still fail as of 06:28Z.

Related reports (same class)

• @deepseek-ai/dsh@0.1.0-rc.6 declares dependency on @deepseek-ai/dsh-compaction-basic@^0.1.0-rc.6, but that package/version does not exist on npm registry. Installation fails with ETARGET. #2991 — 0.1.0-rc.6 declares an unpublished dependency
• [Bug] dsh 0.1.0-rc.8 is not installable from npm: missing dsh-agent-loop@^0.1.0-rc.8 #3461 — 0.1.0-rc.8 not installable (missing dsh-agent-loop@^0.1.0-rc.8)
• pnpm install fails: dsh monolith dependency ranges cannot select published prerelease siblings (0.1.2-rc.1 / 0.1.3-alpha.2) #5969 — monolith prerelease ranges cannot select published siblings
• dsh@0.1.5-rc.1 无法全局安装：依赖 @deepseek-ai/dsh-util-crypto@^0.1.5-rc.1 未发布，导致 ETARGET 错误 #6168 — 0.1.5-rc.1 global install fails with ETARGET on an unpublished dsh-util-crypto@^0.1.5-rc.1
• `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 #7135 — 0.1.5-rc.2 ships incomplete dependencies + stale dist-tags.latest
• dsh-ears imports TypertLookupFailure from @deepseek-ai/dsh-typert-protocol, but no published protocol version exports it #7362 — imports a symbol from a protocol version that was never published

Happy to re-run the checks and post a follow-up with the fixed state if it helps close this out.

[ryanzen9]

The same kind of situation occurred today as well. I hope it can be resolved quickly. 🙏

[Gniy7Ga]

Thanks for the detailed registry evidence. I checked the current npm metadata: dsh-web-app@0.1.5-rc.3 still requires documentpreview@^0.1.5-rc.3, and that leaf version is absent; the latest and next tags are unchanged. I’ve recorded this for the team to investigate the missing dependency and release validation. Your successful alpha installation is a workaround, not confirmation that the affected tags are fixed. We’ll follow up here once a released fix for those install paths is verified.

[kirito1105]

Two things this thread does not have yet: a complete audit of the whole rc.3 dependency set (not just the failing leaf), and a verified working workaround that keeps 0.1.5-rc.2 rather than moving to another version line.

1. Audit: it is exactly one missing package, not a propagation lag

I enumerated every @deepseek-ai/* package that the 0.1.5-rc.3 set demands through ^0.1.5-rc.3 (harvested from npm install --loglevel=verbose against registry.npmjs.org, then each name checked against the official registry): 205 distinct packages.

version	present	missing
0.1.5-rc.1	205 / 205	0
0.1.5-rc.2	205 / 205	0
0.1.5-rc.3	204 / 205	1 — @deepseek-ai/dsh-client-ui-sidebar-documentpreview

So the rest of the wave is intact; this is a single unpublished leaf. That matters for the fix: re-publishing that one package at 0.1.5-rc.3 (and tagging it next) looks like it would restore both next and latest, because rc.2 resolves upward into the same wave.

Verified again just now: GET https://registry.npmjs.org/@deepseek-ai/dsh-client-ui-sidebar-documentpreview/0.1.5-rc.3 → 404 version not found. Still broken as of 2026-09-22 ~16:00 CST.

2. Workaround that keeps you on 0.1.5-rc.2 (no overrides on the CLI)

Pin the one missing leaf with an npm overrides block. Note npm install -g has no --overrides flag in npm 12 (EUNKNOWNCONFIG), so use a local prefix plus npm link:

mkdir D:\dsh-local; cd D:\dsh-local

package.json:

{
  "name": "dsh-local",
  "private": true,
  "dependencies": { "@deepseek-ai/dsh": "0.1.5-rc.2" },
  "overrides": {
    "@deepseek-ai/dsh-client-ui-sidebar-documentpreview": "0.1.5-rc.2"
  }
}

npm install
npm link          # exposes the `dsh` bin globally

Measured result (Windows 11, Node v24.20.0, npm 12.0.1, registry.npmjs.org, fresh install):

• install completed: 518 packages, 2 min
• node node_modules/@deepseek-ai/dsh/lib/bin.js --version → 0.1.5-rc.2
• npm ls → dsh@0.1.5-rc.2 → dsh-web-app@0.1.5-rc.3 → dsh-client-ui-sidebar-documentpreview@0.1.5-rc.2 overridden
• npm ls --all → no invalid / unmet required entries (only the usual cross-platform UNMET OPTIONAL DEPENDENCY for bufferutil, utf-8-validate, @img/sharp-*)

Only that one browser-side plugin ends up at rc.2; the other 229 @deepseek-ai packages in the tree are rc.3. That is the same shape the current latest install already had before the wave landed, so the skew is small — but it is still skew, so this is a stopgap, not a substitute for republishing the leaf.

For the release gate

This is the second instance of this class after dsh-agent-loop@^0.1.0-rc.8, so the missing gate may be worth adding explicitly to the publish pipeline: after a wave publish, resolve every ^<new-version> edge in the wave and fail the release if any target is absent — a single-package gap like this one is invisible to a per-package npm publish success check.

---

中文补充

全量核对：把 0.1.5-rc.3 这批通过 ^0.1.5-rc.3 牵进来的 @deepseek-ai/* 包全部枚举出来共 205 个，逐一查官方 registry —— rc.1 全有、rc.2 全有、rc.3 只缺 dsh-client-ui-sidebar-documentpreview 这一个。所以补发这一个包（并把 next 打上）看起来就能同时修好 next 和 latest，因为 rc.2 会向上解析进同一批。刚复核仍是 404。

可用绕行：npm 12 的 npm install -g 没有 --overrides 参数，改用本地安装 + npm link，在 package.json 里用 overrides 把该包钉到 0.1.5-rc.2。实测 518 个包装完、dsh --version 输出 0.1.5-rc.2、依赖图无 invalid/UNMET；树里只有这一个浏览器侧插件是 rc.2，其余 229 个 @deepseek-ai 包都是 rc.3。属于临时绕行，不能替代补发。

发布门禁建议：这是继 dsh-agent-loop@^0.1.0-rc.8 之后同一类故障的第二次。每个包 npm publish 成功并不能发现这种"单包漏发"，建议发版后对整批 ^<新版本> 依赖边做一次全量解析校验，缺任何一个就让发布失败。

[longxiaolong233]

The @alpha workaround also sits inside the racy window — and this window was ~21 minutes, not seconds

§4 above observed a 20-second race on the alpha wave (06:21:56Z → 06:22:16Z), and the workaround at the bottom recommends npx @deepseek-ai/dsh@alpha web. Both need updating: on the alpha.2 wave the same ordering hazard held dsh@alpha uninstallable for ~21 minutes, and the workaround was not usable for that whole period.

All times UTC, 2026-09-22. Version times read from the registry time field.

time	event
06:23:31	dsh@0.1.7-alpha.1 published
06:38	this thread reports alpha ✅ installing and running
15:50:50	alpha.2 wave starts landing — dsh-session@0.1.7-alpha.2
15:52:13	install → npm never converges: 870 error: 'MISSING' blocks, log reached 5.8 MB at ~1500 lines/s, ran >12 min without terminating
16:01:04	second install → same
16:03:24	npm i --legacy-peer-deps @deepseek-ai/dsh@0.1.7-alpha.1 → ETARGET: @deepseek-ai/dsh-tool-web@0.1.7-alpha.2
16:05:00	dsh-tool-web@0.1.7-alpha.2 published — 96 s after that ETARGET
16:07:45	install → ETARGET: @deepseek-ai/dsh-host-directory-picker-browse@0.1.7-alpha.2
16:08:08	dsh-host-directory-picker-browse@0.1.7-alpha.2 published — 23 s after that ETARGET
16:10:00	230/250 of the wave published, 15 still missing
16:12:34	245/250 published (5 are not on the 0.1.7 line at all), 0 missing → wave complete

Two install attempts, two ETARGETs, each on a leaf that landed seconds later. The window is bounded by the publish job's own duration — here 15:50:50Z → ~16:12Z, i.e. ~21 minutes, about 60× the race in §4.

Enumerating the 250 @deepseek-ai/* packages of an installed 0.1.6 tree against the registry shows the wave fills in package-by-package over that whole period:

16:10:00Z   230 published, 15 missing
16:14Z      231 published,  9 missing
16:12:34Z   245 published,  0 missing

Every install attempt inside the window fails on whichever leaf has not landed yet, which is why retrying gives a different missing package each time instead of the same one.

Two additions to the fix list

A. npm does not fail here — it hangs. Under default peer resolution npm emitted 870 error: 'MISSING' blocks and kept retrying for over 12 minutes without terminating or printing anything a user can distinguish from a hang. --legacy-peer-deps failed fast with ETARGET and was the only way to obtain a diagnosis. Worth accounting for in fix #2: the user-visible failure mode is "npm spins forever", not a clean error, so a --dry-run gate is the only thing that converts it into something actionable.

B. The two waves disagree on peer style, which makes the window unsatisfiable in both directions. alpha.1 packages declare peers as ranges, alpha.2 packages as exact pins:

dsh-session-projection@0.1.7-alpha.1   peer @deepseek-ai/dsh-session: ^0.1.7-alpha.1
dsh-session-projection@0.1.7-alpha.2   peer @deepseek-ai/dsh-session:  0.1.7-alpha.2
dsh-experimental-client-ui-agent-team@0.1.7-alpha.2   — all 13 peers exact

A resolver that backtracks to alpha.1 can still satisfy alpha.1's ranges, but anything that picks an alpha.2 package demands exact alpha.2 siblings that may still be uploading. This also makes resolution non-reproducible across tree shapes: at 16:06:35Z a clean-directory npm install --dry-run @deepseek-ai/dsh@alpha succeeded (585 packages) while at 16:07:45Z npm i -g --prefix <existing 0.1.6 tree> ETARGETed. So a dry-run gate (fix #2) only predicts real upgrades if it runs in a tree shape matching them — exact intra-monorepo pins (fix #4) would remove the ambiguity outright.