[Bug] dsh@0.1.5-rc.2 / rc.3 not installable: missing @deepseek-ai/dsh-client-ui-sidebar-documentpreview@0.1.5-rc.3

[L-Trunks]

Description

npm install -g @deepseek-ai/dsh (latest = 0.1.5-rc.2) currently fails with ETARGET on the official npm registry.

Reproduction

npm install -g @deepseek-ai/dsh

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

Reproduced on Windows and in a clean Linux environment (Node 22.22.2, npm 10.9.7), registry: https://registry.npmjs.org

Root cause

• The 0.1.5-rc.3 release set was published at 2026-09-22T05:55Z.
• @deepseek-ai/dsh-web-app@0.1.5-rc.3 depends on @deepseek-ai/dsh-client-ui-sidebar-documentpreview@^0.1.5-rc.3.
• That version was never published. Available versions of documentpreview: 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.
• Because dsh@0.1.5-rc.2 (the latest tag) declares @deepseek-ai/dsh-web-app@^0.1.5-rc.2, the caret range resolves to the broken rc.3, so the latest install is broken too, not only @next.

Workarounds

• npm install -g @deepseek-ai/dsh@alpha (0.1.7-alpha.1) resolves correctly.
• Local install with "overrides": { "@deepseek-ai/dsh-web-app": "0.1.5-rc.2" } also resolves.

Suggested fix

Publish @deepseek-ai/dsh-client-ui-sidebar-documentpreview@0.1.5-rc.3, or deprecate @deepseek-ai/dsh-web-app@0.1.5-rc.3.

Possibly the same class of issue as #3461 (rc.8 missing dsh-agent-loop). A CI check that verifies every package in a release set is published before tagging might prevent this.

[PerryLink]

Independently confirmed against the live registry - it reproduces exactly. The part worth adding is why the range cannot fall forward, because that is what makes the failure total rather than partial.

Read from registry.npmjs.org just now:

@deepseek-ai/dsh                                    latest=0.1.5-rc.2     next=0.1.5-rc.3   alpha=0.1.7-alpha.1
@deepseek-ai/dsh-web-app                            latest=0.0.1-rc.1     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
  documentpreview 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 is not in that list. @deepseek-ai/dsh@0.1.5-rc.2 declares @deepseek-ai/dsh-web-app: ^0.1.5-rc.2, and asking npm what that range covers:

$ 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'

Two matches, and the highest - 0.1.5-rc.3 - is what an install picks. dsh-web-app@0.1.5-rc.3 declares @deepseek-ai/dsh-client-ui-sidebar-documentpreview: ^0.1.5-rc.3, and for that range npm reports 404 No match found for version ^0.1.5-rc.3. So every link in your chain holds, including the transitive one that takes latest down with it.

Why it cannot fall forward: a prerelease range is only satisfied by a prerelease with the same major.minor.patch. The same rule on the same package, as a control:

$ npm view "@deepseek-ai/dsh-web-app@^0.1.6-alpha.1" version
@deepseek-ai/dsh-web-app@0.1.6-alpha.1 '0.1.6-alpha.1'
@deepseek-ai/dsh-web-app@0.1.6-alpha.2 '0.1.6-alpha.2'

0.1.7-alpha.1 exists and is not listed. That is the whole mechanism - nothing in the registry can satisfy ^0.1.5-rc.3, so the ETARGET is correct rather than a resolver quirk. It also predicts the blast radius you measured: next fails directly on rc.3, and latest fails transitively through the caret.

Why it happened. This is not a version that failed to upload: documentpreview was not part of the rc.3 set at all. Its own next tag still points at 0.1.5-rc.2, while dsh and dsh-web-app both moved next to 0.1.5-rc.3.

On your CI suggestion, a concrete place for it. scripts/release/publish.ts publishes a packed directory in a recorded order, and its stated completeness guarantee is that "every entry in the order settles as either published or already present" (:143-145), with a genuine integrity check for the already-present case (:155-166). Nothing in that run asks whether the declared ranges of the entries it just published are resolvable on the registry - which is precisely the gap rc.3 went through. A post-publish pass that resolves each intra-set range the way the commands above do would have caught it while latest was still untouched, which is the part that made it user-visible.

Your workaround checks out too: alpha is 0.1.7-alpha.1, whose dsh-web-app is 0.1.7-alpha.1, whose documentpreview range is ^0.1.7-alpha.1 and resolves. So npm install -g @deepseek-ai/dsh@alpha is sound end to end.

One unrelated observation, same class of tag hygiene: @deepseek-ai/dsh-web-app's own latest is still 0.0.1-rc.1.

[Gniy7Ga]

Thanks for the reproduction and independent registry check. We have linked this report to the existing investigation into the missing documentpreview rc.3 dependency, including its impact on the rc.2/latest installation path. The alpha workaround does not establish that the affected release channels are restored. We will follow up here once the fix and an available release covering these installation paths are verified.

[PerryLink]

Update on my own analysis above: both halves of the fix have shipped, so the conclusion I wrote is now stale in the reporter's favour.

When I checked, latest pointed at 0.1.5-rc.2 and the missing member did not exist. Read from the registry just now:

$ npm view "@deepseek-ai/dsh-client-ui-sidebar-documentpreview@^0.1.5-rc.3" version
0.1.5-rc.3                     <- the range resolves now; it was "404 No match found" before

@deepseek-ai/dsh dist-tags:
  latest : 0.1.5-rc.3          <- was 0.1.5-rc.2
  next   : 0.1.5-rc.3
  alpha  : 0.1.7-alpha.2

So the missing package was published and the tag was moved onto it - the first of the two options I listed. A plain npm install -g @deepseek-ai/dsh should resolve again; a machine still holding the rc.2 pin just needs to reinstall.

Two things from the mechanism that are still worth keeping, because they describe the class rather than this instance:

• The failure was hard, not graceful, because of prerelease matching. ^0.1.5-rc.3 cannot be satisfied by 0.1.6-alpha.2 or 0.1.7-alpha.1 - a prerelease range only matches a prerelease of the same major.minor.patch - so there was nothing to fall back to. Publishing the member fixed this case; it did not remove the reason a future one would be equally silent.
• The guard I suggested is still not there. The release tooling still states its own completeness contract as "Every entry in the order settles as either published or already present" (scripts/release/publish.ts:143-145), and I did not find a step that resolves the declared ranges of the entries it just published. That remains the cheapest way to catch this before a tag move makes it user-visible.

Boundary: registry values above were read live today; the source line was read at HEAD 00102833df (dsh-v0.1.7-alpha.2). I did not run an install to confirm the end-to-end resolve.

[dsh-community-assistant[bot]]

Thanks for the update. I independently checked the official npm registry: @deepseek-ai/dsh-client-ui-sidebar-documentpreview@^0.1.5-rc.3 now resolves to 0.1.5-rc.3, and both latest and next for @deepseek-ai/dsh point to 0.1.5-rc.3. That confirms the previously missing version is now available.

I have not yet verified a clean install and Web startup across the affected paths, so I’m keeping that verification separate from the registry correction. The release-set validation concern also remains open; publishing this package does not by itself establish that the preventive check is in place.

[turtle1999]

this should have been fixed