dshmarket 1.20.0 → 1.20.2

package/lib/dsh-cli.js

@@ -143,15 +143,56 @@ export function proxyEnvForPnpm(env = process.env, region = 'global') {
     }
     return out;
 }
+/**
+ * Directories to append to PATH so a spawned pnpm can be found (#32, #38,
+ * #167, #292).
+ *
+ * A GUI or desktop launch inherits none of the shell profile, so PATH holds
+ * whatever the launcher had — usually not the directory the user's package
+ * manager lives in. The market appends the places it is actually installed
+ * to rather than telling the user to fix their environment.
+ *
+ * Windows used to get only the Node directory, which made the market's own
+ * advice unfollowable: the error it prints recommends installing pnpm with
+ * `iwr https://get.pnpm.io/install.ps1`, and then it did not look where that
+ * installer puts it (#292). Both Windows layouts are covered now — the
+ * standalone installer's `%LOCALAPPDATA%\pnpm`, and `%APPDATA%\npm` where
+ * `npm i -g pnpm` writes `pnpm.cmd`.
+ *
+ * `PNPM_HOME` comes first on every platform: the installer sets it, so it is
+ * the one answer that is right even when the layout is not the default one.
+ *
+ * @param platform - `process.platform`, injectable for tests.
+ * @param env - environment, for PNPM_HOME and the Windows app-data roots.
+ * @param home - home directory, injectable for tests.
+ */
+export function toolSearchDirs(platform = process.platform, env = process.env, home = homedir()) {
+    const dirs = [];
+    const pnpmHome = (env.PNPM_HOME ?? '').trim();
+    if (pnpmHome !== '')
+        dirs.push(pnpmHome);
+    if (platform === 'win32') {
+        const local = (env.LOCALAPPDATA ?? '').trim();
+        const roaming = (env.APPDATA ?? '').trim();
+        if (local !== '')
+            dirs.push(join(local, 'pnpm'));
+        if (roaming !== '')
+            dirs.push(join(roaming, 'npm'));
+    }
+    else {
+        dirs.push('/opt/homebrew/bin', '/usr/local/bin', join(home, '.local', 'bin'));
+        // Where the standalone installer lands when PNPM_HOME is unset.
+        dirs.push(join(home, 'Library', 'pnpm'), join(home, '.local', 'share', 'pnpm'));
+    }
+    dirs.push(nodeBinDir, ...extraPathDirs);
+    return dirs;
+}
 function spawnEnv() {
     // pnpm v10+ blocks forever on a silent interactive prompt without a TTY;
     // CI mode forces it to act or fail instead of asking.
     const separator = process.platform === 'win32' ? ';' : ':';
     const parts = (process.env.PATH ?? '').split(separator).filter(part => part !== '');
-    const candidates = process.platform === 'win32'
-        ? [nodeBinDir, ...extraPathDirs]
-        : ['/opt/homebrew/bin', '/usr/local/bin', join(homedir(), '.local', 'bin'), nodeBinDir, ...extraPathDirs];
-    for (const bin of candidates) {
+    for (const bin of toolSearchDirs()) {
         if (!parts.includes(bin))
             parts.push(bin);
     }
@@ -417,7 +458,13 @@ export function provisionHint(corepackOutput, npmOutput, npmFound = true) {
     // holds on a Windows console that reports the same thing in a codepage we
     // cannot read (#167); the ENOENT match stays for callers without it.
     if (!npmFound || (/ENOENT/.test(corepackOutput) && /ENOENT/.test(npmOutput))) {
-        return `这台机器的 dsh 进程找不到 npm/corepack（图形界面或桌面端启动时不继承终端 PATH）。已在 Node 自己的目录里找过（${nodeBinDir}）也没有——多半是宿主内置的 Node 运行时不带 npm。请改从终端启动 dsh，或单独装一个 pnpm：Windows 用 iwr https://get.pnpm.io/install.ps1 -useb | iex，macOS/Linux 用 brew install pnpm / This dsh process cannot find npm/corepack (GUI and desktop launches skip your shell PATH). The directory Node itself runs from (${nodeBinDir}) was searched too — a bundled Node runtime without npm is the usual cause. Start dsh from a terminal, or install pnpm on its own: \`iwr https://get.pnpm.io/install.ps1 -useb | iex\` (Windows) or \`brew install pnpm\` (macOS/Linux)`;
+        // The searched list is spelled out because the previous wording named
+        // only the Node directory, which was both incomplete and unhelpful: a
+        // user who HAD installed pnpm could not tell whether we looked in the
+        // right place (#292). And the restart note matters — the installer sets
+        // PNPM_HOME for new sessions, so a dsh already running cannot see it.
+        const searched = toolSearchDirs().join(process.platform === 'win32' ? ' ; ' : ' : ');
+        return `这台机器的 dsh 进程找不到 npm/corepack（图形界面或桌面端启动时不继承终端 PATH）——多半是宿主内置的 Node 运行时不带 npm。已找过：${searched}。请改从终端启动 dsh，或单独装一个 pnpm：Windows 用 iwr https://get.pnpm.io/install.ps1 -useb | iex，macOS/Linux 用 brew install pnpm。装完后请重启 dsh——安装器只对新开的会话生效，正在运行的进程看不到它 / This dsh process cannot find npm/corepack (GUI and desktop launches skip your shell PATH); a bundled Node runtime without npm is the usual cause. Searched: ${searched}. Start dsh from a terminal, or install pnpm on its own: \`iwr https://get.pnpm.io/install.ps1 -useb | iex\` (Windows) or \`brew install pnpm\` (macOS/Linux). Restart dsh afterwards — the installer only affects new sessions, so an already-running process cannot see it`;
     }
     if (/EEXIST|already exists|--force to overwrite/i.test(npmOutput)) {
         return 'pnpm 的可执行文件已存在（通常是 corepack 先放好了同名 shim），npm 拒绝覆盖。在终端里执行其一即可：corepack prepare pnpm@latest --activate（推荐，直接激活已有 shim）或 npm i -g pnpm --force / A pnpm executable already exists (usually a corepack shim), so npm refused to overwrite it. Run one of these in a terminal: `corepack prepare pnpm@latest --activate` (preferred — activates the shim already there) or `npm i -g pnpm --force`';

package/lib/pnpm-compat.js

@@ -105,6 +105,28 @@ export function classifyPnpmFailure(output) {
             message: `这个 profile 的 node_modules 链接到的 pnpm store，和当前 pnpm 默认使用的 store 不是同一个，pnpm 因此拒绝所有安装与卸载。${detail}\n在 profile 目录里执行一次 \`pnpm install --store-dir <上面第一个路径>\` 重新链接即可（dsh 运行时可能占用文件，必要时先退出 dsh）/ this profile's node_modules is linked to a different pnpm store than the one pnpm now resolves, so pnpm refuses every install and uninstall.${detail}\nRelink by running \`pnpm install --store-dir <the first path above>\` once in the profile directory (stop dsh first if files are locked)`,
         };
     }
+    // #222 by @MicroMilo: a patch in the profile that no longer applies.
+    //
+    // pnpm exits 1 (verified against 10.29.3) but it has ALREADY written the
+    // package — unpatched. So the profile is left holding the pristine version
+    // the patch existed to fix, and the damage shows up at the next boot as
+    // "failed to load plugins" rather than here, where it happened.
+    //
+    // Almost always the package moved the file the patch names: the reported
+    // case patched `client/client.js` in a package that had started shipping
+    // `lib/client.js`. That is not something the market can repair — the patch
+    // is the user's, and guessing a new target would be inventing a change
+    // they did not write — so it says exactly what is wrong and where.
+    if (output.includes('ERR_PNPM_PATCH_FAILED')) {
+        const patch = /Could not apply patch (\S+)/.exec(output)?.[1];
+        const which = patch === undefined ? '' : `（${patch}）`;
+        const whichEn = patch === undefined ? '' : ` (${patch})`;
+        return {
+            code: 'patch-failed',
+            recoverable: false,
+            message: `profile 里的一个 pnpm 补丁打不上了${which}。pnpm 会继续把这个包装上，但装的是没打补丁的原版——通常下次启动才会以「插件加载失败」暴露出来。多半是包升级后挪动了补丁指向的文件（例如补丁改的是 client/client.js，而新版本发的是 lib/client.js）。请更新或删掉这个补丁文件，以及 profile package.json 里 pnpm.patchedDependencies 中对应的那一条 / a pnpm patch in this profile no longer applies${whichEn}. pnpm still installs the package, but unpatched — which usually surfaces at the next boot as "failed to load plugins" rather than here. The usual cause is the package moving the file the patch targets (for example a patch against client/client.js when the release now ships lib/client.js). Update or remove that patch file and its entry under pnpm.patchedDependencies in the profile's package.json`,
+        };
+    }
     if (output.includes('ERR_PNPM_ADDING_TO_ROOT')) {
         return {
             code: 'adding-to-root',

package/lib/types/dsh-cli.d.ts

@@ -54,6 +54,30 @@ export declare const nodeBinDir: string;
  * must keep excluding it.
  */
 export declare function proxyEnvForPnpm(env?: NodeJS.ProcessEnv, region?: Region): NodeJS.ProcessEnv;
+/**
+ * Directories to append to PATH so a spawned pnpm can be found (#32, #38,
+ * #167, #292).
+ *
+ * A GUI or desktop launch inherits none of the shell profile, so PATH holds
+ * whatever the launcher had — usually not the directory the user's package
+ * manager lives in. The market appends the places it is actually installed
+ * to rather than telling the user to fix their environment.
+ *
+ * Windows used to get only the Node directory, which made the market's own
+ * advice unfollowable: the error it prints recommends installing pnpm with
+ * `iwr https://get.pnpm.io/install.ps1`, and then it did not look where that
+ * installer puts it (#292). Both Windows layouts are covered now — the
+ * standalone installer's `%LOCALAPPDATA%\pnpm`, and `%APPDATA%\npm` where
+ * `npm i -g pnpm` writes `pnpm.cmd`.
+ *
+ * `PNPM_HOME` comes first on every platform: the installer sets it, so it is
+ * the one answer that is right even when the layout is not the default one.
+ *
+ * @param platform - `process.platform`, injectable for tests.
+ * @param env - environment, for PNPM_HOME and the Windows app-data roots.
+ * @param home - home directory, injectable for tests.
+ */
+export declare function toolSearchDirs(platform?: string, env?: NodeJS.ProcessEnv, home?: string): string[];
 /**
  * Windows npm/corepack/pnpm are `.cmd` shims. Node's `spawn` without a shell
  * cannot start them (ENOENT / EINVAL). Same pattern as dsh's `plugin` forwarder.

package/lib/types/pnpm-compat.d.ts

@@ -32,7 +32,7 @@ export declare function pluginArgsFor(profileDir: string, pluginArgs: string[]):
  */
 export declare const HOST_NAMESPACE_RE: RegExp;
 export interface PnpmFailure {
-    code: 'adding-to-root' | 'not-a-workspace' | 'hoist-pattern-diff' | 'pnpm-missing' | 'release-age-violation' | 'ignored-builds' | 'git-prepare-not-allowed' | 'fetch-404' | 'transient-network' | 'fetch-timeout' | 'unexpected-store';
+    code: 'adding-to-root' | 'not-a-workspace' | 'hoist-pattern-diff' | 'pnpm-missing' | 'release-age-violation' | 'ignored-builds' | 'git-prepare-not-allowed' | 'fetch-404' | 'transient-network' | 'fetch-timeout' | 'unexpected-store' | 'patch-failed';
     /** Bilingual, actionable message shown to the user instead of the raw wall of text. */
     message: string;
     /** True when re-running `pnpm install` in the profile is the documented recovery. */

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "dshmarket",
   "description": "Visual plugin market inside DeepSeek Harness — browse, search, and one-click install community plugins. · DSH 可视化插件市场：逛一逛，点一下，装好。",
-  "version": "1.20.0",
+  "version": "1.20.2",
   "type": "module",
   "main": "lib/index.js",
   "types": "lib/types/index.d.ts",

package/src/dsh-cli.ts

@@ -144,15 +144,57 @@ export function proxyEnvForPnpm(env: NodeJS.ProcessEnv = process.env, region: Re
   return out
 }
 
+/**
+ * Directories to append to PATH so a spawned pnpm can be found (#32, #38,
+ * #167, #292).
+ *
+ * A GUI or desktop launch inherits none of the shell profile, so PATH holds
+ * whatever the launcher had — usually not the directory the user's package
+ * manager lives in. The market appends the places it is actually installed
+ * to rather than telling the user to fix their environment.
+ *
+ * Windows used to get only the Node directory, which made the market's own
+ * advice unfollowable: the error it prints recommends installing pnpm with
+ * `iwr https://get.pnpm.io/install.ps1`, and then it did not look where that
+ * installer puts it (#292). Both Windows layouts are covered now — the
+ * standalone installer's `%LOCALAPPDATA%\pnpm`, and `%APPDATA%\npm` where
+ * `npm i -g pnpm` writes `pnpm.cmd`.
+ *
+ * `PNPM_HOME` comes first on every platform: the installer sets it, so it is
+ * the one answer that is right even when the layout is not the default one.
+ *
+ * @param platform - `process.platform`, injectable for tests.
+ * @param env - environment, for PNPM_HOME and the Windows app-data roots.
+ * @param home - home directory, injectable for tests.
+ */
+export function toolSearchDirs(
+  platform: string = process.platform,
+  env: NodeJS.ProcessEnv = process.env,
+  home: string = homedir(),
+): string[] {
+  const dirs: string[] = []
+  const pnpmHome = (env.PNPM_HOME ?? '').trim()
+  if (pnpmHome !== '') dirs.push(pnpmHome)
+  if (platform === 'win32') {
+    const local = (env.LOCALAPPDATA ?? '').trim()
+    const roaming = (env.APPDATA ?? '').trim()
+    if (local !== '') dirs.push(join(local, 'pnpm'))
+    if (roaming !== '') dirs.push(join(roaming, 'npm'))
+  } else {
+    dirs.push('/opt/homebrew/bin', '/usr/local/bin', join(home, '.local', 'bin'))
+    // Where the standalone installer lands when PNPM_HOME is unset.
+    dirs.push(join(home, 'Library', 'pnpm'), join(home, '.local', 'share', 'pnpm'))
+  }
+  dirs.push(nodeBinDir, ...extraPathDirs)
+  return dirs
+}
+
 function spawnEnv(): NodeJS.ProcessEnv {
   // pnpm v10+ blocks forever on a silent interactive prompt without a TTY;
   // CI mode forces it to act or fail instead of asking.
   const separator = process.platform === 'win32' ? ';' : ':'
   const parts = (process.env.PATH ?? '').split(separator).filter(part => part !== '')
-  const candidates = process.platform === 'win32'
-    ? [nodeBinDir, ...extraPathDirs]
-    : ['/opt/homebrew/bin', '/usr/local/bin', join(homedir(), '.local', 'bin'), nodeBinDir, ...extraPathDirs]
-  for (const bin of candidates) {
+  for (const bin of toolSearchDirs()) {
     if (!parts.includes(bin)) parts.push(bin)
   }
   return { ...process.env, ...proxyEnvForPnpm(process.env, activeRegion()), CI: 'true', PATH: parts.join(separator) }
@@ -491,7 +533,13 @@ export function provisionHint(corepackOutput: string, npmOutput: string, npmFoun
   // holds on a Windows console that reports the same thing in a codepage we
   // cannot read (#167); the ENOENT match stays for callers without it.
   if (!npmFound || (/ENOENT/.test(corepackOutput) && /ENOENT/.test(npmOutput))) {
-    return `这台机器的 dsh 进程找不到 npm/corepack（图形界面或桌面端启动时不继承终端 PATH）。已在 Node 自己的目录里找过（${nodeBinDir}）也没有——多半是宿主内置的 Node 运行时不带 npm。请改从终端启动 dsh，或单独装一个 pnpm：Windows 用 iwr https://get.pnpm.io/install.ps1 -useb | iex，macOS/Linux 用 brew install pnpm / This dsh process cannot find npm/corepack (GUI and desktop launches skip your shell PATH). The directory Node itself runs from (${nodeBinDir}) was searched too — a bundled Node runtime without npm is the usual cause. Start dsh from a terminal, or install pnpm on its own: \`iwr https://get.pnpm.io/install.ps1 -useb | iex\` (Windows) or \`brew install pnpm\` (macOS/Linux)`
+    // The searched list is spelled out because the previous wording named
+    // only the Node directory, which was both incomplete and unhelpful: a
+    // user who HAD installed pnpm could not tell whether we looked in the
+    // right place (#292). And the restart note matters — the installer sets
+    // PNPM_HOME for new sessions, so a dsh already running cannot see it.
+    const searched = toolSearchDirs().join(process.platform === 'win32' ? ' ; ' : ' : ')
+    return `这台机器的 dsh 进程找不到 npm/corepack（图形界面或桌面端启动时不继承终端 PATH）——多半是宿主内置的 Node 运行时不带 npm。已找过：${searched}。请改从终端启动 dsh，或单独装一个 pnpm：Windows 用 iwr https://get.pnpm.io/install.ps1 -useb | iex，macOS/Linux 用 brew install pnpm。装完后请重启 dsh——安装器只对新开的会话生效，正在运行的进程看不到它 / This dsh process cannot find npm/corepack (GUI and desktop launches skip your shell PATH); a bundled Node runtime without npm is the usual cause. Searched: ${searched}. Start dsh from a terminal, or install pnpm on its own: \`iwr https://get.pnpm.io/install.ps1 -useb | iex\` (Windows) or \`brew install pnpm\` (macOS/Linux). Restart dsh afterwards — the installer only affects new sessions, so an already-running process cannot see it`
   }
   if (/EEXIST|already exists|--force to overwrite/i.test(npmOutput)) {
     return 'pnpm 的可执行文件已存在（通常是 corepack 先放好了同名 shim），npm 拒绝覆盖。在终端里执行其一即可：corepack prepare pnpm@latest --activate（推荐，直接激活已有 shim）或 npm i -g pnpm --force / A pnpm executable already exists (usually a corepack shim), so npm refused to overwrite it. Run one of these in a terminal: `corepack prepare pnpm@latest --activate` (preferred — activates the shim already there) or `npm i -g pnpm --force`'

package/src/pnpm-compat.ts

@@ -45,7 +45,7 @@ export const HOST_NAMESPACE_RE = /^@deepseek-ai\//
 export interface PnpmFailure {
   code: 'adding-to-root' | 'not-a-workspace' | 'hoist-pattern-diff' | 'pnpm-missing' | 'release-age-violation'
     | 'ignored-builds' | 'git-prepare-not-allowed' | 'fetch-404' | 'transient-network' | 'fetch-timeout'
-    | 'unexpected-store'
+    | 'unexpected-store' | 'patch-failed'
   /** Bilingual, actionable message shown to the user instead of the raw wall of text. */
   message: string
   /** True when re-running `pnpm install` in the profile is the documented recovery. */
@@ -131,6 +131,28 @@ export function classifyPnpmFailure(output: string): PnpmFailure | null {
       message: `这个 profile 的 node_modules 链接到的 pnpm store，和当前 pnpm 默认使用的 store 不是同一个，pnpm 因此拒绝所有安装与卸载。${detail}\n在 profile 目录里执行一次 \`pnpm install --store-dir <上面第一个路径>\` 重新链接即可（dsh 运行时可能占用文件，必要时先退出 dsh）/ this profile's node_modules is linked to a different pnpm store than the one pnpm now resolves, so pnpm refuses every install and uninstall.${detail}\nRelink by running \`pnpm install --store-dir <the first path above>\` once in the profile directory (stop dsh first if files are locked)`,
     }
   }
+  // #222 by @MicroMilo: a patch in the profile that no longer applies.
+  //
+  // pnpm exits 1 (verified against 10.29.3) but it has ALREADY written the
+  // package — unpatched. So the profile is left holding the pristine version
+  // the patch existed to fix, and the damage shows up at the next boot as
+  // "failed to load plugins" rather than here, where it happened.
+  //
+  // Almost always the package moved the file the patch names: the reported
+  // case patched `client/client.js` in a package that had started shipping
+  // `lib/client.js`. That is not something the market can repair — the patch
+  // is the user's, and guessing a new target would be inventing a change
+  // they did not write — so it says exactly what is wrong and where.
+  if (output.includes('ERR_PNPM_PATCH_FAILED')) {
+    const patch = /Could not apply patch (\S+)/.exec(output)?.[1]
+    const which = patch === undefined ? '' : `（${patch}）`
+    const whichEn = patch === undefined ? '' : ` (${patch})`
+    return {
+      code: 'patch-failed',
+      recoverable: false,
+      message: `profile 里的一个 pnpm 补丁打不上了${which}。pnpm 会继续把这个包装上，但装的是没打补丁的原版——通常下次启动才会以「插件加载失败」暴露出来。多半是包升级后挪动了补丁指向的文件（例如补丁改的是 client/client.js，而新版本发的是 lib/client.js）。请更新或删掉这个补丁文件，以及 profile package.json 里 pnpm.patchedDependencies 中对应的那一条 / a pnpm patch in this profile no longer applies${whichEn}. pnpm still installs the package, but unpatched — which usually surfaces at the next boot as "failed to load plugins" rather than here. The usual cause is the package moving the file the patch targets (for example a patch against client/client.js when the release now ships lib/client.js). Update or remove that patch file and its entry under pnpm.patchedDependencies in the profile's package.json`,
+    }
+  }
   if (output.includes('ERR_PNPM_ADDING_TO_ROOT')) {
     return {
       code: 'adding-to-root',