@deepseek-ai/dsh-llm@0.1.3-alpha.2: dsh-attachment and dsh-invariants missing from published dependencies

[musichen]

Summary

@deepseek-ai/dsh-llm's public type surface imports directly from both @deepseek-ai/dsh-attachment and @deepseek-ai/dsh-invariants:

• FileAttachmentRef/ImageAttachmentRef from dsh-attachment in src/index.ts, src/content.ts, and src/types.ts
• InvariantFailure/InvariantInstaller from dsh-invariants in src/invariant.ts, which backs the package's own published ./invariant subpath export

Both are declared under devDependencies in packages/llm/llm/package.json instead of dependencies. devDependencies never ship in a published npm tarball, so any consumer resolving dsh-llm's types under NodeNext/bundler module resolution hits TS2724: has no exported member on FileAttachmentRef (and would hit the same on InvariantFailure/InvariantInstaller for the ./invariant subpath).

@deepseek-ai/cordis correctly stays in devDependencies since it's already declared as a peerDependency — this is specifically about the two that aren't peers.

Repro

npm view @deepseek-ai/dsh-llm@0.1.3-alpha.2 dependencies
# missing dsh-attachment / dsh-invariants

pnpm --dir packages/llm/llm pack --pack-destination /tmp/before
# tarball's package.json "dependencies" also missing both, confirming it's not
# a one-off publish glitch — the current package.json itself misclassifies them

Hit while upgrading a downstream consumer from @deepseek-ai/dsh-llm@0.1.1-rc.2 to 0.1.3-alpha.2.

Suggested fix

Move both entries from devDependencies to dependencies in packages/llm/llm/package.json. I verified locally that pnpm pack then correctly includes both in the tarball's dependencies at ^0.1.3-alpha.2.

Since I understand external PRs aren't being accepted right now, I've pushed the verified fix (4-line package.json change + regenerated lockfile) on a branch here in case it's useful as a reference: https://github.com/musichen/deepseek-harness/tree/fix/dsh-llm-attachment-invariants-dependencies

[pradipNP]

Your diagnosis looks correct. Since dsh-llm imports dsh-attachment and dsh-invariants as part of its published API, they should be listed under dependencies, not devDependencies.

The fact that npm view @deepseek-ai/dsh-llm@0.1.3-alpha.2 dependencies doesn't include them confirms that consumers won't receive those packages when installing dsh-llm.

Moving both packages to dependencies and republishing the package should resolve the missing-module/type-resolution issue for downstream consumers. Your pnpm pack verification is also a good way to confirm the generated package metadata before publishing.

So I agree with the proposed fix; this looks like a packaging/dependency classification issue rather than a TypeScript configuration problem.

[Mide69]

Confirmed independently, two ways.

Read packages/llm/llm/package.json on current master directly: both @deepseek-ai/dsh-attachment and @deepseek-ai/dsh-invariants really are under devDependencies, sitting right next to @deepseek-ai/cordis (which is correctly there since it's already a peerDependency). And I ran npm view @deepseek-ai/dsh-llm@0.1.3-alpha.2 dependencies --json myself just now against the live registry, not just reading source, same result: only zod, dsh-brand, dsh-timeout, schemastery, dsh-util-crypto, dsh-util-values, dsh-typert-protocol show up. No dsh-attachment, no dsh-invariants. So this is live and broken right now, not something already fixed since your report or a one-off tarball glitch.

Also checked the exports field, since that settles whether ./invariant is really public API or something more internal: it's a real subpath export, "./invariant": { "types": "./lib/types/invariant.d.ts", "default": "./lib/invariant.js" }, published right alongside the main entry. So InvariantFailure/InvariantInstaller aren't reachable through some undocumented internal path, they're behind an explicitly published entry point, which makes the devDependencies placement unambiguous, not a borderline call.

Your fix (move both to dependencies) is the correct and minimal one. Good idea pushing a reference branch given CONTRIBUTING.md doesn't take PRs right now, that gives a maintainer a diff to just apply rather than rederive.

[musichen]

Update: still open, live-broken as of today, two independent confirmations

Confirming this is still reproducible right now against the current registry and current master — nothing has changed since the original report.

Two independent confirmations so far, both verified against source and the live registry:

• @pradipNP: "Your diagnosis looks correct... they should be listed under dependencies, not devDependencies... this looks like a packaging/dependency classification issue rather than a TypeScript configuration problem."
• @Mide69: independently re-verified both by reading packages/llm/llm/package.json on current master and by querying npm view @deepseek-ai/dsh-llm@0.1.3-alpha.2 dependencies --json against the live registry directly, confirmed ./invariant is an explicitly published subpath export (not internal), and concluded: "Your fix (move both to dependencies) is the correct and minimal one."

I attempted to open this as a formal PR so there'd be a reviewable diff + CI, but PR creation against this repo appears to be fully disabled at the platform level (not just unreviewed — gh pr create fails with a CreatePullRequest permission error, and the repo has zero PRs in its history, open or closed). So instead, here's the verified fix as a direct branch comparison against current master:

master...musichen:deepseek-harness:fix/dsh-llm-attachment-invariants-dependencies

It's a 2-file, 4-line manifest change (packages/llm/llm/package.json + regenerated pnpm-lock.yaml), no source changes. Ready to cherry-pick directly.

Tagging a few of the most active contributors on this repo in case it helps surface this for triage, per the guidance in CONTRIBUTING.md to bring reports here for the team's attention: @tianyicui @LegGasai @imccyu @Chinesezjc @kermanx

[musichen]

Additional visibility

Widening the cc to more of the repo's most active contributors, in case anyone here owns packaging/publishing for dsh-llm or knows who does:

@tianyicui @LegGasai @Chinesezjc @kermanx @CreatixChu @turtle1999 @pku-xht @ZiyaZhang @Kingwl @Dudu-0223 @Elevator14B @NI0317

For anyone landing here fresh: this is a 2-file, 4-line devDependencies → dependencies manifest fix for packages/llm/llm/package.json, independently confirmed twice (@pradipNP, @Mide69), still reproducible live today, verified diff here:

master...musichen:deepseek-harness:fix/dsh-llm-attachment-invariants-dependencies