dsh plugin add fails on pnpm 12 with ERR_PNPM_ADDING_TO_ROOT

[mushan0x0]

"## dsh plugin add fails on pnpm 12 with ERR_PNPM_ADDING_TO_ROOT\n\n### What happened\n\nInstalling a plugin into a profile fails before pnpm even starts resolving the package:\n\nsh\ndsh plugin --profile demo add <package>\n\n\n\n ERR_PNPM_ADDING_TO_ROOT Running this command will add the dependency to the workspace root, which might not be what you want - if you really meant it, make it explicit by running this command again with the -w flag (or --workspace-root). If you don't want to see this warning anymore, you may set the ignore-workspace-root-check setting to true.\nCommand failed with exit code 1: pnpm add '<package>'\ndsh: plugin command failed; diagnostics: <profile>/.plugin-manager/logs/operation-XXXX/pnpm.log\n\n\n### Why\n\nA profile is its own pnpm workspace \u2014 <profile>/pnpm-workspace.yaml contains packages: [.] \u2014 so the profile directory is the workspace root. The plugin manager runs pnpm add <spec> inside it without --workspace-root, and pnpm 12 rejects that combination as an error (in pnpm 10 and 11 the same call only warned).\n\nSo dsh plugin add is unusable on a machine with pnpm 12, for every package, tarball included.\n\n### Repro\n\nAny profile, any spec, with pnpm 12 on PATH:\n\nsh\ndsh plugin --profile demo add <package>\n\n\n### Workaround\n\nRun the add by hand in the profile directory with -w, then add the package to dsh.profile.bundles:\n\nsh\ncd <profile>\npnpm add <package> -w\n\n\n### Suggestion\n\nEither pass --workspace-root in the plugin manager's pnpm invocation, or set ignore-workspace-root-check: true in the profile's pnpm-workspace.yaml it generates \u2014 the second keeps the manager's pnpm call unchanged and matches the setting pnpm's own error message points at.\n"

[PerryLink]

The workspace is fine; the pnpm that runs is the variable.

A profile really is its own workspace: initProfile writes pnpm-workspace.yaml with packages: [.] plus nodeLinker: hoisted and autoInstallPeers: false (packages/boot/app-boot/src/profile.ts:183-188, written at :215). dsh plugin forwards the rest of the argv to pnpm with the profile as cwd and no -w (apps/cli/src/plugin.ts:98 → plugin-manager/src/operations.ts:296, execa at :369 with cwd: dir).

Where I disagree: pnpm 12 did not reject that shape in my runs. Same directory, same files, pnpm add is-number@7.0.0:

pnpm	result
9.15.0	ERR_PNPM_ADDING_TO_ROOT
10.0.0	ERR_PNPM_ADDING_TO_ROOT
11.0.0	adds
12.0.0 / 12.4.0 / 12.6.0 / 12.8.1 / 12.16.1	adds

So the safeguard is on 9/10, not on 11/12 as far as I can measure. That points at the binary dsh resolves, not the version printed in a different shell: the CLI uses pnpm from PATH (bin.ts → runPlugin with no package manager), while Desktop passes its own bundled pnpm (11.28.5 in apps/desktop/package.json:76). Check pnpm --version in the environment that launches dsh.

Immediate workaround: dsh plugin --profile demo add -w <package>. The -w is forwarded verbatim, and I verified it on 9.15 and 12.16.

On the two fixes: adding --workspace-root to the manager's root-mutating verbs is the narrow one. Writing ignore-workspace-root-check: true into the generated pnpm-workspace.yaml also works, but it applies to everything in that profile afterwards and hides the same ambiguity for future commands, so I would not make it the default.