@open-design/dsh-runtime: git installs are broken — no prepare script, dist never built, sources stripped by files field

[striveprince]

Summary

Installing dsh-runtime as a git dependency (github:nexu-io/open-design#path:packages/dsh-runtime, e.g. via pnpm add -w into a DeepSeek Harness profile) produces a broken package: the declared entry points (main: dist/index.js, exports["./startup"] -> dist/startup.js) do not exist, and they can never be built on the consumer side. On DSH Desktop this hard-fails the entire plugin tree at startup (the loader applies plugin entries atomically), so one broken package takes the whole app down.

Root cause (verified against main @ 7e365ac)

1. No prepare script. packages/dsh-runtime/package.json only declares build / test / typecheck. pnpm executes a git dependency's prepare hook at install time — but a bare build script is never run automatically. Modern pnpm (v10+) also gates all build scripts behind its allow-build policy; once allowed, it still looks for prepare, finds nothing, and silently installs without building. pnpm rebuild cannot help for the same reason — there is no hook to rebuild through.
2. Sources are not shipped in the installed package. The files field publishes only dist/*.js, dist/types/**, cordis.patch.yml and README.md. Consequently the installed package directory contains only README.md, cordis.patch.yml, package.json (+ hoisted node_modules). src/, tsconfig.json, esbuild.config.ts, clean.ts are absent, so consumers cannot even build locally to work around (1).
3. No published npm package to fall back on. @open-design/dsh-runtime has zero versions on the npm registry.

Net effect: main/exports point at files that no installation path can ever produce.

Evidence

DSH Desktop startup log after installing the plugin:

[E] [host-resolved-root-include] Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'C:\Users\<user>\.dsh\profiles\desktop\node_modules\@open-design\dsh-runtime\dist\startup.js' imported from ...package.json
[E] [host-resolved-root-include] Error: failed to import loader entry open-design-startup (@open-design/dsh-runtime/startup): Cannot find module ...
[E] [host-resolved-root-include] Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'C:\Users\<user>\.dsh\profiles\desktop\node_modules\@open-design\dsh-runtime\dist\index.js' imported from ...package.json
[E] [host-resolved-root-include] Error: failed to import loader entry open-design-runtime (@open-design/dsh-runtime): Cannot find module ...
Error: dsh-plugin-desktop: plugin tree failed to load: failed to apply loader entry include (cordis:include): loader entries failed to apply
AggregateError: loader entries failed to apply

Installed package contents vs. repo contents of packages/dsh-runtime:

installed	in repo
README.md	clean.ts missing
cordis.patch.yml	esbuild.config.ts missing
package.json	src/ missing
	tests/ missing
	tsconfig(.tests).json missing
	dist/ never built

Environment: Windows 10 x64, Node 25.6.0, pnpm 11.7.0, DSH Desktop kernel @deepseek-ai/dsh@0.1.1-rc.2 (peer ranges are satisfied — peerDependencies look correct now; this report is purely about packaging/build wiring).

Suggested fix

Any one of these resolves it:

1. Add a prepare hook (minimal, standard for git-dependency consumption):

// packages/dsh-runtime/package.json
"scripts": {
  "prepare": "pnpm run build",
  "build": "tsx ./clean.ts && tsx ./esbuild.config.ts && tsc -p tsconfig.json --emitDeclarationOnly"
}

2. Publish a prebuilt dist/ tarball/npm version so installers don't need to build at all.
3. At minimum, fail loud and early: add a check that errors clearly when dist/index.js is missing on startup/install, instead of letting the consumer's loader die with an opaque ERR_MODULE_NOT_FOUND inside an atomic tree load.

Happy to re-test on Windows + pnpm 11.7 once a fix lands on main.

[open-design-bot]

🎉 ✨ Welcome to Open Design, @striveprince!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @striveprince, thanks for the precise write-up — the package-contents comparison made this straightforward to verify.

I checked packages/dsh-runtime/package.json on the current main: it points main / exports at dist/index.js and dist/startup.js, but the package only defines a build script, not a prepare hook, and the files list excludes the build inputs (src/, tsconfig.json, esbuild.config.ts, clean.ts). That means the git-dependency install path can't produce the declared entrypoints, which matches the startup failure you're seeing.

I’ve labeled this as bug + help wanted. Your suggested directions look reasonable from here — either make the git-install path buildable, or ship prebuilt artifacts for this package so consumers never need to build it themselves. If you want to put up a PR, we’re happy to review.

[lefarcen]

If you'd like to take this on, comment /claim and we can track it here.

[lefarcen]

PR #7475 takes the minimal fix path proposed here by adding a prepare hook in packages/dsh-runtime/package.json, so git/path installs run the existing build and produce dist/ before the package is linked. Keeping this issue open until that change lands and someone re-tests the install path.