Third-party profile bundles fail with ERR_MODULE_NOT_FOUND: runProfile never passes bareModuleBaseUrl to boot()

[cnctem]

Context: I'm the developer of dsh-acp, a community (third-party) plugin that bridges ACP clients (Zed, VS Code) to dsh agents. I hit this while distributing my plugin as a profile bundle — this blocks any third-party bundle that isn't shipped inside dsh's own node_modules.

Bug: third-party profile bundles fail to load — runProfile does not pass bareModuleBaseUrl to boot()

Version: @deepseek-ai/dsh@0.1.1-rc.2 (latest on npm), Node.js v20.19.0, macOS

Summary

A profile that declares a third-party bundle (a community plugin not shipped inside dsh's own node_modules) crashes at startup with ERR_MODULE_NOT_FOUND, even though the package is correctly installed in the profile's node_modules. Built-in bundles (@deepseek-ai/dsh-base, etc.) load fine because they resolve from dsh's own install tree.

Reproduction

1. Create a profile with a third-party bundle, e.g. ~/.dsh/profiles/acp/package.json:

{
  "name": "dsh-profile-acp",
  "private": true,
  "dependencies": {
    "dsh-acp": "link:/path/to/dsh-acp"
  },
  "dsh": {
    "profile": {
      "bundles": ["@deepseek-ai/dsh-base", "dsh-acp"]
    }
  }
}

2. Run dsh --profile acp (or spawn it via an ACP client).

3. The process exits with code 1:

failed to import loader entry acp (dsh-acp): Cannot find package 'dsh-acp' imported from
.../@deepseek-ai/dsh/node_modules/@deepseek-ai/cordis-plugin-loader/lib/index.js
[cause]: Error [ERR_MODULE_NOT_FOUND] ...

Root cause

runProfile (lib/profile-boot-*.js) calls:

const ctx = await boot(NAME, rootConfig, structuredClone(allPatches(composed)), (hostCtx) => { ... });

— without the 5th argument bareModuleBaseUrl. Consequently mountRootInclude (in @deepseek-ai/dsh-app-boot) installs the plain Include builtin instead of HostResolvedRootInclude, and Include.import() resolves bare package names with a plain dynamic import() from the loader module's own location (cordis-plugin-loader/lib/index.js). Node's resolution then only walks dsh's install tree and never sees ~/.dsh/profiles/<profile>/node_modules, so third-party bundles can never be found.

The bareModuleBaseUrl parameter appears to be designed exactly for this ("optional installed-host base for bare package names"), but the CLI never wires it up.

Suggested fix

Pass the profile directory as the bare-module base when booting a profile, e.g.:

await boot(NAME, rootConfig, patches, prepare, pathToFileURL(join(composed.profile.dir, 'package.json')).href);

so that bare specifiers resolve against the profile's node_modules (including the healed ~/.dsh/profiles/node_modules fallback).

Workaround

Globally installing/linking the third-party bundle (e.g. npm i -g dsh-acp) places it in the global node_modules, which happens to be in the loader's upward node_modules chain for a globally installed dsh. This unblocks local development but is not viable for distributing a plugin to end users — npm i -g dsh-acp shouldn't be a prerequisite for dsh --profile acp to work.