DSH 0.2.1-alpha.2 does not boot from a pnpm 11 global install (native binding resolved from the loader's own module context)

[antst]

Environment: macOS arm64, pnpm 11.18.0, pnpm add -g @deepseek-ai/dsh@0.2.1-alpha.2.
Any dsh --profile <p> ... boot (including --help) fails:

dsh: fatal uncaught exception: Error: dsh: host preparation failed:
No usable native binding found for node-addon-require-builtin-darwin-arm64 (auto)

Chain: @deepseek-ai/cordis-plugin-loader@1.0.6-alpha.1 ->
node-addon-require-builtin@0.1.9 -> node-addon-native-custom-loader@0.1.9.

The binding is installed correctly: the lockfile records
node-addon-require-builtin-darwin-arm64@0.1.9 (os darwin, cpu arm64,
optional), the store has it with prebuilt/darwin-arm64-napi-v9.node, and
it is linked as a sibling of node-addon-require-builtin. The failure is
in how the loader looks for it (node-addon-native-custom-loader 0.1.9,
lib index.js):

• tryRequirePackage (around line 454) does a bare
  require('node-addon-require-builtin-darwin-arm64') from the LOADER's
  own module context, not from the package that depends on the binding.
• The workspace fallback checks
  join(packageDir, '..', platformPackageSuffix()) where the suffix is the
  literal 'darwin-arm64' (around lines 288-290), a sibling name that
  does not exist under pnpm (the sibling is the full package name).
• The local-build fallbacks need a build/ directory the registry
  package does not ship.

Why ordinary installs work, and the global one does not:

• Classic project layout: packages live under
  /node_modules/.pnpm/, so the hoist directory
  /node_modules/.pnpm/node_modules is on the loader's realpath
  walk-up and the bare require resolves.
• pnpm project .bin shims also export NODE_PATH containing that hoist
  directory.
• A pnpm 11 global install has neither: real paths are in
  /v11/links/ (off any walk-up) and the global shim exports no
  NODE_PATH.

Minimal repro without DSH: with the node the shim uses,
require('/.../node-addon-require-builtin/lib/index.js') fails
with the same message. Controls: the same version boots from a plain
project install with the same pnpm (direct bin.js, no NODE_PATH); a
project with enableGlobalVirtualStore: true fails when its shim is
bypassed. DSH 0.1.2 with the 0.1.5 loader (same code) booted from the
same global layout because that version did not reach this path at boot.

Workaround: NODE_PATH=/node_modules/.pnpm/node_modules.

Suggested fix: resolve the optional candidate from the dependent
package, e.g. require.resolve(request, { paths: [packageDir] }), and
check the sibling under its full package name.

[antst]

Confirmed on the same host (macOS arm64, pnpm 11.18.0): a second workaround that keeps the global install. Adding "enableGlobalVirtualStore: false" to pnpm's global pnpm-workspace.yaml (macOS: ~/Library/pnpm/global/v11/pnpm-workspace.yaml) and reinstalling ("pnpm remove -g @deepseek-ai/dsh && pnpm add -g @deepseek-ai/dsh@0.2.1-alpha.2") makes pnpm place the virtual store inside the global environment ("Virtual store is at: .../global/v11//node_modules/.pnpm"), which puts the hoist directory back on the loader's realpath walk-up; "env -u NODE_PATH dsh --profile

--help" then boots. The loader-side fix is still the right one, since the setting changes the layout of every global package.