[Bug] 0.1.5-alpha.2: published dsh-client-store omits Zustand/Immer runtime dependencies

[yuezengwu]

@deepseek-ai/dsh-client-store@0.1.5-alpha.2 cannot be imported after a clean npm install: its published lib/index.js still imports zustand/vanilla, zustand/middleware, zustand/shallow, and immer, but the manifest lists both packages only in devDependencies. The same isolated import succeeds with 0.1.5-alpha.1.

Environment: macOS arm64, Node v24.20.0, npm 11.19.0. Also reproduced in a standalone plugin using pnpm 11.7.0.

Reproduction in a new empty directory:

npm init -y
npm install --ignore-scripts --no-audit --no-fund @deepseek-ai/dsh-client-store@0.1.5-alpha.2 @deepseek-ai/cordis@4.0.2
node --input-type=module -e "await import('@deepseek-ai/dsh-client-store'); console.log('import ok')"

Actual result (exit 1):

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'zustand' imported from .../@deepseek-ai/dsh-client-store/lib/index.js

Expected: the import resolves all runtime dependencies. Repeating these steps in another empty directory with 0.1.5-alpha.1 prints import ok and exits 0.

Tagged manifests:

• alpha.1: Immer and Zustand are runtime dependencies
• alpha.2: they are only development dependencies

Downstream impact: dsh-explain's clean published-package test run fails while loading its client store. A narrowly scoped pnpm packageExtensions entry restores immer: ^10.1.1 and zustand: ~4.4.7 to this exact package version's runtime dependencies; all 80 plugin tests then pass. The built alpha.2 source host also passes the plugin's 7 Web and 3 combination scenarios, since its workspace already installs those development dependencies. This report concerns standalone consumption of the published package; it does not establish that the shipped DSH Web application fails to boot.

Suggested upstream resolution: retain these as runtime dependencies while the emitted package imports them, or bundle the implementations into the published artifact. A packed-package import smoke outside the source workspace would catch the regression.

Downstream workaround and compatibility evidence are now merged in dsh-explain PR #36. Its published-package job and five pinned-source host CI jobs all pass; the workaround does not change the upstream package.

[argszero]

@yuezengwu Confirmed — and it is broader than the one package you hit. I reproduced it exactly on 0.1.5-alpha.2 (macOS arm64, Node v24) and traced it to a single release commit. Below are the facts, the blast radius, and one constraint that will bite your suggested fix.

Reproduction (your steps, verbatim)

npm init -y
npm install --ignore-scripts --no-audit --no-fund @deepseek-ai/dsh-client-store@0.1.5-alpha.2 @deepseek-ai/cordis@4.0.2
node --input-type=module -e "await import('@deepseek-ai/dsh-client-store'); console.log('import ok')"

→ Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'zustand' imported from .../dsh-client-store/lib/index.js. The installed manifest really does carry dependencies: undefined with zustand ~4.4.7 + immer ^10.1.1 under devDependencies, and the artifact really does still import them:

from "immer"
from "zustand/middleware"
from "zustand/shallow"
from "zustand/vanilla"

Root cause: one commit, two package shapes, one of them wrong

f39a37a523 — "fix(client): keep browser dependencies out of production installs" (2026-09-08, in the alpha.2 train) moved third-party runtime deps into devDependencies across 21 client manifests. For most of them that is correct, because their build inlines everything. But the repo has two client build modes, and the commit applied one rule to both:

mode	artifact	third-party bare imports
clientBundle (16 pkgs)	lib/client.js closure-factory	inlined — verified: dsh-client-ui-attachment ships zero bare imports
staticLinked (5 pkgs)	lib/index.js ESM	kept as imports — by explicit contract

packages/client/tsdown.client.ts, staticLinkedConfig — contract 1, verbatim:

"every bare specifier stays an import. The shell attributes chunk bytes by node_modules/<pkg>, so a dependency inlined into a workspace file is attributed to no npm package and its bytes fall into the index chunk, which collapses the vendor/index cache split."

So for staticLinked packages the bare imports are required, while their manifests no longer declare the packages those imports name. The artifact and the manifest now disagree — which is exactly the ERR_MODULE_NOT_FOUND you saw.

Blast radius: 4 of the 5 staticLinked packages

Verified by installing each and importing it standalone:

package	standalone import	first missing specifier
dsh-client-store	✗ fails	zustand (+ immer)
dsh-client-ui-primitives	✗ fails	react, react-dom, clsx, katex, shiki/@shikijs/langs, micromark-*, mdast-*, anser
dsh-client-ui-dockkit	✗ fails	react, react-dom, clsx
dsh-client-web	✗ fails	cordis-plugin-loader, react-dom, cordis, dsh-client-store, …
dsh-client-ui-slots	✓ ok	— (imports are type-only, erased)

ui-slots is the useful control: it is staticLinked but happens to emit no bare imports, so it survives. That confirms the trigger is "staticLinked and non-type third-party import", not staticLinked alone.

Your "does the shipped app break" caution is right — and here is why

The DSH Web application is not affected. PLATFORM_MODULES (packages/client/web/src/platform.ts:8-15) shares exactly the affected set into the frozen module table:

'react', 'react/jsx-runtime', 'react-dom', 'react-dom/client', '@deepseek-ai/cordis',
'@deepseek-ai/dsh-client-store', '@deepseek-ai/dsh-client-ui-slots',
'@deepseek-ai/dsh-client-ui-primitives', '@deepseek-ai/dsh-client-ui-dockkit',

apps/web resolves those from the workspace and owns the chunk layout — it is the consumer the bare imports are for. I checked the transitive hop too: dsh-api-session-controller imports the value notifySubscribers from the store and keeps it external (the store is in the baseline externals), so it lands on the shell's copy rather than a broken one. Your report is correctly scoped to standalone published-package consumption.

⚠️ Constraint on your suggested fix (the part worth knowing before opening anything)

Your pnpm packageExtensions workaround works because it repairs the manifest after install. But restoring the entries to dependencies in-tree will be rejected by the repository's own gate:

scripts/verify-package-dependencies.ts:578-584 classifies every non-workspace third-party source use as devDependencies —

add(name, 'devDependencies', 'declared browser build input')

— and then asserts must be devDependencies-only against the manifest (:692). So dependencies.{zustand,immer} fails the gate today. The commit that caused this also added scripts/browser-bundled-externals.ts, which resolves these same third-party inputs but only to feed THIRD_PARTY_NOTICES.md; it explicitly re-marks them external: true (i.e. it knows they stay imports) and never checks that the manifest declares them. Nothing in the gate set covers "what a published artifact still imports must be resolvable by its consumer".

So there are two coherent shapes, and the choice is a maintainer call:

1. Restore the runtime declarations for staticLinked packages (your reading), and exempt them from the devDependencies-only rule. Small, matches the module split the preset already encodes; costs a standalone install a transitive zustand/react pull.
2. Make staticLinked bundle third-party libraries, keeping only workspace / module-table specifiers external. Preserves "no browser deps in production installs" exactly, but trades away the vendor/index cache split that contract 1 exists to protect.

Either way the missing piece is a regression guard, which is the strongest suggestion in your report: a packed-tarball import smoke (npm pack each published package, install into an empty dir, import() it) would have caught this at release time — the same class of gate already exists for other published surfaces.

Plugin-mountability note (task bookkeeping)

I checked whether this is reachable as a plugin contribution: it is not. The defect is what a published core package declares in its own manifest, and a plugin cannot amend another package's published manifest — the only lever is consumer-side (packageExtensions), which is precisely your workaround rather than a fix. Verdict: packaging/core face, plugin is a downstream victim — so this belongs upstream as a manifest + gate change, and I have recorded it that way rather than proposing a plugin.

Thanks for including the tag-diff links and the clean-install repro — they made this a five-minute trace instead of a research project.

[PerryLink]

Verified against the current source and the published artifacts - the regression is wider than one package, and it is still present in 0.1.5-rc.1.

Range from the published manifest of @deepseek-ai/dsh-client-store:

version	zustand / immer
0.1.2-alpha.2 ... 0.1.5-alpha.1	dependencies (correct)
0.1.5-alpha.2	devDependencies only (first bad)
0.1.5-rc.1	devDependencies only (still bad)

So the last good release is 0.1.5-alpha.1, the first bad one is 0.1.5-alpha.2, and 0.1.5-rc.1 - which is what the next tag currently points at - is still affected.

This is not a publish-time difference: the source manifest at 0.1.5-rc.1 (packages/client/store/package.json) also declares both packages in devDependencies. Unless the manifest is corrected in the source, the next rc and the stable release will carry the same defect.

Two practical notes:

1. Installing without pinning a line is not affected, because latest still points at 0.1.2-alpha.2.
2. Workaround until the manifest is fixed: declare the runtime peers yourself (npm install zustand immer alongside the package), or pin @deepseek-ai/dsh-client-store@0.1.5-alpha.1.

One-line way to re-check the range:

curl -s https://registry.npmjs.org/@deepseek-ai%2Fdsh-client-store | node -e "const m=JSON.parse(require('fs').readFileSync(0,'utf8'));for(const [v,p] of Object.entries(m.versions))console.log(v, p.dependencies&&p.dependencies.zustand?'deps':'devDeps')"

[yuezengwu]

Thanks @argszero and @PerryLink for reproducing this and identifying the static-linked packaging/gate mismatch. I checked the tagged rc.2 source: staticLinked still preserves bare imports, while the dependency policy still treats browser inputs as development dependencies. A source-level fix needs to make those two policies agree.

Fresh standalone npm installs on 2026-09-11 (macOS arm64, Node 24.20.0) give:

dsh-client-store version	direct import without a workaround
0.1.5-alpha.1	succeeds
0.1.5-rc.1	fails: missing zustand
0.1.5-rc.2	fails: missing zustand

The manifests for both release candidates still list Zustand/Immer only under devDependencies. Current CLI distribution tags have moved: latest=0.1.5-rc.1, next=0.1.5-rc.2, alpha=0.1.5-alpha.2. Earlier statements about the default CLI channel remaining on an unaffected old version are therefore historical, not current.

The downstream workaround is merged in dsh-explain PR #38: packageExtensions matches only alpha.2, rc.1 and rc.2, with the original Zustand/Immer ranges. The repaired rc.2 published-package checks pass; seven pinned source hosts each pass 80 unit/integration tests, 7 assembled-Web scenarios and 3 shortcut scenarios. All eight PR CI checks pass.

This does not repair the other static-linked packages, alter upstream manifests, or establish a DSH Web boot failure. I am keeping this report open for the upstream packaging decision and a packed-artifact consumption regression check.