[Bug][NixOS] rc.7 dsh web crashes because disabled HMR is recreated without loader internals

[Kurumi-yyy]

Summary

On a fresh NixOS user state, the documented dsh web command from the official npm release exits before the Web UI becomes available:

Error: failed to apply loader entry ... (@deepseek-ai/cordis-plugin-hmr): --expose-internals is required for HMR service

This is an independent reproduction of the same failure family reported in #1873, #690, #1276, and #752. This report adds a clean rc.7 reproduction on Nix-built Node.js 24.19.0, with no historical DSH configuration imported.

Environment

• NixOS under WSL2, x86_64-linux, glibc
• Nix-built Node.js v24.19.0
• @deepseek-ai/dsh@0.1.0-rc.7 from the official npm registry
• @deepseek-ai/cordis-plugin-hmr@1.0.16
• @deepseek-ai/cordis-plugin-loader@1.0.2
• Fresh ~/.dsh; no historical DSH state imported
• Empty workspace used for the smoke test

Reproduction

npm install --global @deepseek-ai/dsh@0.1.0-rc.7
dsh web --host 127.0.0.1 --port 3080 --no-open

Observed result:

• Process exits with status 1.
• 127.0.0.1:3080 never becomes reachable.
• No listener or residual DSH process remains after exit.

Configuration evidence

The shipped default configuration reports the HMR row as disabled:

- id: hmr
  name: '@deepseek-ai/cordis-plugin-hmr'
  config:
    root:
      - .
  disabled: true

The Web bundle also documents the intent explicitly:

# TODO: Re-enable shared HMR for Web after its reload lifecycle is tested.
- id: hmr
  disabled: true

However, the post-boot path in apps/cli/src/profile-boot.ts creates a new watch-only HMR instance whenever ctx.get('hmr') is undefined. A deliberately disabled row therefore becomes absence of the service, which triggers recreation:

if (ctx.get('hmr') === undefined) {
  if (ctx.get('timer') === undefined) {
    await ctx.loader.create({ name: '@deepseek-ai/cordis-plugin-timer' })
  }
  await ctx.loader.create({ name: '@deepseek-ai/cordis-plugin-hmr', config: { root: [] } })
}

On this Nix-built Node binary, loader internals are unavailable through the flag-free fallback, and the recreated HMR constructor fails hard. This matches the detailed root-cause analysis in #1873 and #752.

Clarification and verified temporary workaround

This is not evidence that a Nix-built Node binary is generally unable to run DSH. The Web application itself starts successfully when Node exposes the loader internals before loading DSH. The incompatibility is narrower: the current flag-free/native fallback used by the recreated HMR service cannot obtain those internals on this Node build.

I verified the following command shape using the installed package's real lib/bin.js path:

node --expose-internals /path/to/@deepseek-ai/dsh/lib/bin.js \
  web --host 127.0.0.1 --port 3080 --no-open

Verified result on the environment above:

• DSH printed dsh web: http://127.0.0.1:3080 and remained running.
• An HTTP request to / returned status 200.
• The response was text/html; charset=utf-8 with a non-empty Web UI document (14,549 bytes).
• The original HMR --expose-internals is required failure did not occur.

This is a diagnostic workaround, not a proposed permanent requirement: --expose-internals exposes unsupported Node internals and must be supplied as a Node startup option before the DSH JavaScript entry point. The normal dsh web ... launcher still fails in the same clean environment.

Expected behavior

The documented command should start the Web UI on a supported NixOS/Node environment without requiring an undocumented manual launcher.

Any of these upstream changes would resolve the boot failure safely:

1. Respect an explicitly disabled HMR row and do not recreate it as a mandatory post-boot service.
2. If loader internals are unavailable, skip config-only HMR with a clear warning rather than terminating the harness.
3. Provide and document a supported launcher path that supplies the required Node capability.

Suggested acceptance test:

• Run the published npm CLI with a nixpkgs-built Node binary.
• Execute dsh web --host 127.0.0.1 --port 3080 --no-open from a fresh user state.
• Verify that http://127.0.0.1:3080 becomes reachable without modifying the shipped profile or injecting an undocumented workaround.

Related reports

• [Bug] dsh web crashes on Nix-built Node: HMR entry force-created despite bundle disable; native addon fallback fails (--expose-internals is required for HMR service) #1873 — same disabled-HMR recreation path on Nix-built Node
• NixOS 上 HMR 服务报 --expose-internals is required: node-addon-require-builtin 探测在 Nix 编译的 Node 上失败 #690 — NixOS/native fallback incompatibility
• npx @deepseek-ai/dsh web 全新安装后崩溃：--expose-internals is required for HMR service #1276 — fresh npm install on Node.js 24.19.0
• `pnpm dsh web` / `--profile headless` fail to boot from source on Node 24.18.1 — `node-addon-require-builtin` incompatible, silent fallback masks the root cause #752 — regression history and flag-free fallback analysis

Thank you for releasing DSH as open source. I hope this additional clean reproduction and acceptance test help prioritize a robust fix for NixOS and other source-built Node environments.

[ylwl1997]

The rc.7 clean-Nix repro is useful: a disabled: true HMR row is still treated as “missing” in profile-boot.ts, so the CLI recreates @deepseek-ai/cordis-plugin-hmr and that constructor dies when loader internals are not exposed. Same family as #1873 / #2699, just with a fresh ~/.dsh and nixpkgs Node 24.19.0.

Your node --expose-internals …/lib/bin.js web … check already proves the Web UI itself is fine. A slightly less brittle launcher (survives global upgrades without hunting bin.js) is:

NODE_OPTIONS=--expose-internals dsh web --host 127.0.0.1 --port 3080 --no-open

On NixOS, wrapping the dsh binary with that env is more durable than a manual path. --expose-internals is still an unsupported Node flag, so this is only a boot strap — the durable fix is still “do not recreate a disabled HMR service” / “degrade to a warning when internals are unavailable,” as you listed in the acceptance test.

[sysarcher]

Reproduced on my machine — same version and same environment family:

• OS: NixOS 26.05 (BUILD_ID 26.05.20260817.0dd31db), kernel 6.18.44 x86_64, glibc 2.42
• Node: v24.19.0 from nixpkgs nodejs-slim (invoked through a flox env → /nix/store/…-nodejs-slim-24.19.0/bin/node)
• dsh: 0.1.0-rc.7 via pnpm 11.17.0

Confirming the root cause in isolation — the native-addon fallback probe fails on the Nix-built binary:

node -e "require('node-addon-require-builtin').requireBuiltin('internal/modules/esm/loader')"
→ node-addon-require-builtin unsupported: Unsupported/no-getter
  (x64 sysv getter is not a recognized this->field accessor
   (wide-window retry: x64 sysv getter is not a recognized this->field accessor))

So ctx.loader.internal is undefined and the recreated HMR constructor throws.

One correction to the workaround above: NODE_OPTIONS=--expose-internals does not work — Node rejects it outright ("--expose-internals is not allowed in NODE_OPTIONS"). The flag has to be passed on the node command line, which is the only thing that boots for me:

node --expose-internals node_modules/.pnpm/@deepseek-ai+dsh@0.1.0-rc.7_*/node_modules/@deepseek-ai/dsh/lib/bin.js web --port 0 --no-open

This also means a plain npx @deepseek-ai/dsh web can't be salvaged via env vars on this platform — agreeing the durable fixes are "don't recreate a disabled HMR service" and "degrade to a warning when internals are unavailable."

[ylwl1997]

Thanks @sysarcher — that's a real correction, not a nit.

I just rechecked: --expose-internals is rejected inside NODE_OPTIONS (is not allowed in NODE_OPTIONS), so the env-var launcher I posted will never boot a nixpkgs Node. The flag has to be on the node argv, which is why only this form works on your machine:

node --expose-internals <path-to-@deepseek-ai/dsh/lib/bin.js> web --host 127.0.0.1 --port 3080 --no-open

npx @deepseek-ai/dsh web / a wrapped dsh binary cannot be salvaged via env on this platform. Retracting the NODE_OPTIONS recipe.

The durable fixes remain the ones in the OP: do not recreate a disabled: true HMR row, and degrade to a warning when ctx.loader.internal is missing.