ERR_MODULE_NOT_FOUND for bundle plugins when dsh is installed with pnpm (non-flat node_modules)

[tongsh6]

Environment

• @deepseek-ai/dsh 0.1.0-rc.6
• Node.js v22.22.2
• pnpm 11.20.0 (isolated node_modules layout, global virtual store on another drive)
• Windows 11 (win32 x64)

Repro

pnpm add -g @deepseek-ai/dsh
dsh web

Boot fails with dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include). The aggregate error contains:

Cannot find package '@deepseek-ai/cordis-plugin-timer' imported from ...\cordis-plugin-loader\lib\index.js
Cannot find package '@deepseek-ai/dsh-llm' imported from ...
Cannot find package '@deepseek-ai/dsh-client-ui-plan' imported from ...
(4 entries total)

The same package boots fine via npx @deepseek-ai/dsh web, which produces npm's flat node_modules layout.

Analysis

Two separate problems surfaced:

1. The flat fallback misses transitive bundle plugins. dsh-app-boot maintains $DSH_HOME/profiles/node_modules as "one symlink per package in the dsh app's resolvable dependency closure". Under pnpm's isolated layout the closure walk comes up short: links are created for packages @deepseek-ai/dsh reaches directly, but bundle plugins such as @deepseek-ai/dsh-llm and @deepseek-ai/dsh-client-ui-plan get no link, and @deepseek-ai/cordis-plugin-timer gets a dangling one. Their plain dynamic import(name) fallback in cordis-plugin-loader then throws ERR_MODULE_NOT_FOUND, because with pnpm the loader's own real path can only see the loader's declared dependencies.

2. Self-healing via the profile install also fails. Installing the bundles into the profile (dsh plugin --profile web add @deepseek-ai/dsh-base @deepseek-ai/dsh-web-app) produces an incomplete tree: the generated pnpm-workspace.yaml pins autoInstallPeers: false, while the plugins peer-depend on each other (e.g. @deepseek-ai/dsh-llm imports @deepseek-ai/dsh-timeout, which never gets installed). After this, boot fails for every plugin entry (~110 ERR_MODULE_NOT_FOUND errors), which is worse than the initial state.

Workaround

A dedicated hoisted install boots fine and the Web UI serves on 127.0.0.1:3080:

# pnpm-workspace.yaml next to a package.json that depends on @deepseek-ai/dsh
packages:
  - .
nodeLinker: hoisted
autoInstallPeers: true
allowBuilds:
  '@deepseek-ai/dsh-subprocess-local': true
  '@google/genai': true
  koffi: true
  node-pty: true
  protobufjs: true

Suggestion

• Build the profiles/node_modules fallback from the full bundle closure (or resolve plugin specifiers relative to the profile directory before falling back to a plain import()), and/or
• generate the profile scaffold with autoInstallPeers: true, so pnpm-managed installs behave like the npm/npx flat layout.

[tongsh6]

Follow-up: Web UI directory picker drops trailing characters of some CJK folder names (Windows)

On the same install, creating a workspace via the Web UI folder picker fails when the selected folder's leaf name is 阳朔攀岩:

workspace create failed: workspace-invalid-path: cannot create a workspace at
"D:\work\worklog-private\00-EC+\10-projects\亚玛芬\始祖鸟\阳朔": ENOENT: no such file or directory

The picked leaf name 阳朔攀岩 (4 CJK chars) reaches the backend as 阳朔 — its last two characters are dropped. Ancestor CJK segments (亚玛芬, 始祖鸟) and the + in 00-EC+ come through intact, and selecting a different CJK-named folder as the workspace (...\亚玛芬\始祖鸟, 3-char leaf) works fine — so it is not a blanket CJK/encoding failure, only certain leaf names are affected.

Env: dsh 0.1.0-rc.6, Windows 11, Chrome, web profile (running from the hoisted install described above).