[BUG] 发现构建脚本在 pnpm 11 下失败的问题：runScript 错误地用 Node 执行包管理器

[Mingze1208]

环境信息

• 操作系统：Ubuntu（WSL2）
• Node.js 版本：v22.23.1
• pnpm 版本：11.22.0
• 项目：deepseek-harness

问题描述

运行 pnpm run build 时出现以下错误：

file:///home/user/.local/share/pnpm/store/v11/links/@pnpm/exe/11.22.0/.../node_modules/@pnpm/exe/pnpm:1
ELF
^

SyntaxError: Invalid or unexpected token
    at compileSourceTextModule (node:internal/modules/esm/utils:346:16)
    ...

该错误表明 Node.js 正在尝试将 pnpm 可执行文件当作 JavaScript 模块加载。根据 pnpm 安装方式的不同，该文件可能是 ELF 二进制文件或 POSIX shell 脚本，但两者都不是合法的 JavaScript 代码。

根本原因

在 scripts/build.ts 文件中，runScript 函数使用了以下方式执行包脚本：

const packageManager = process.env.npm_execpath
const result = spawnSync(process.execPath, [packageManager, 'run', script], {
  cwd: resolve(import.meta.dirname, '..'),
  env: environment,
  stdio: 'inherit',
})

该代码实际执行的是：

node /path/to/pnpm run build:lib

也就是说，它使用 Node.js 去运行包管理器的入口文件。在旧版 pnpm 中，入口文件可能是 JavaScript 文件，但在 pnpm 11 中，入口变成了 shell 脚本（POSIX shell script）或 ELF 二进制文件。Node 无法解析这些格式，因此抛出 SyntaxError 或 ELF 错误。

建议的修复方案

不要用 Node 去执行包管理器，而是直接运行包管理器的入口文件，并让系统 shell 处理 shebang：

const result = spawnSync(packageManager, ['run', script], {
  cwd: resolve(import.meta.dirname, '..'),
  env: environment,
  stdio: 'inherit',
  shell: true,   // <-- 添加这一行
})

此修改在 Linux/macOS（入口为 shell 脚本）和 Windows（入口为 .cmd 文件）上均可正常工作。shell: true 选项确保系统 shell 能够正确解析文件。

补充说明

• 直接运行 pnpm run build:lib 没有问题，只有 build.ts 中的包装逻辑会失败。
• 该问题与 pnpm 的安装方式无关（独立二进制版或 corepack/npm 安装版都会出现相同错误）。
• 这可能是构建脚本中的一个 bug，在 pnpm 更改入口文件格式后暴露出来。

期望的行动

请更新 scripts/build.ts，使用 shell: true 直接执行包管理器入口文件。或者，根据包管理器类型检测并采用合适的执行方式。

感谢！

[denial123789]

The root-cause classification is correct: rc.8 assumes npm_execpath is JavaScript and unconditionally constructs node <entrypoint> run .... With pnpm 11 that path may be an ELF binary or an executable POSIX launcher, so the failure occurs before build:lib starts.

I would avoid making shell: true the shared fix, though. It changes quoting, metacharacter expansion, executable resolution, signal handling, and injection behavior on every platform. The path from npm_execpath should remain an argument/data value, not become part of a shell command contract.

A safer cross-platform helper should classify the concrete entrypoint:

• .js / .cjs / .mjs: run through process.execPath;
• native ELF, Mach-O, extensionless binary, or .exe: spawn the entrypoint directly;
• executable POSIX launcher with a valid shebang: spawn directly and let the kernel honor the shebang;
• .cmd / .bat: resolve a documented JavaScript/native target or use an explicit Windows-only branch, rather than silently enabling shell parsing everywhere.

The helper should be shared by build.ts, run-gates.ts, run-web-snapshots.ts, and the coverage runners; fixing only the first caller leaves the same assumption elsewhere. Regression tests need paths containing spaces, non-ASCII, and metacharacters, plus exit/signal/stdio parity.

I expanded the existing runbook in place (rather than publishing a duplicate): canonical revision 2 · visual execution map.

Disclosure: I maintain the independent SandBase DeepSeek Harness Handbook.