@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.

[Levier123]

@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.

[Mide69]

Tried to reproduce just now by checking the live npm registry directly and could not:

$ npm view "@deepseek-ai/dsh-compaction-basic@^0.1.0-rc.6" version
@deepseek-ai/dsh-compaction-basic@0.1.0-rc.6 '0.1.0-rc.6'
@deepseek-ai/dsh-compaction-basic@0.1.0-rc.7 '0.1.0-rc.7'

The range resolves fine right now. Checked publish timestamps too, no ordering issue either:

@deepseek-ai/dsh-compaction-basic@0.1.0-rc.6: 2026-08-13T12:12:55Z
@deepseek-ai/dsh@0.1.0-rc.6:                  2026-08-13T12:35:03Z

The dependency was published about 22 minutes before the dependent package, so this was not a publish-ordering race at release time.

One thing that IS odd and might be worth a separate report: npm view @deepseek-ai/dsh-compaction-basic dist-tags currently shows:

{ "latest": "0.0.1-rc.3", "next": "0.1.0-rc.7" }

latest is stuck on a much older pre-rc.6 version while next has the current release. If any tooling in your install path resolves an unpinned reference to this package through the latest tag instead of the exact range in dsh's own package.json, that could produce exactly this kind of "version does not exist" confusion, though a plain ^0.1.0-rc.6 range as declared should ignore dist-tags entirely and go straight to the matching published version.

Do you still hit the ETARGET error if you retry now? If so, it'd help to know your exact install command, npm/pnpm version, and whether you're going through a private registry mirror or proxy, since a stale cache there could also produce this.