pnpm v11 的安全策略，让我踩了个坑

起因

最近在 Jenkins 上构建项目时突然报错，打开 Console Output 一看，赫然是这么一条错误信息：

yaml 复制代码

ERR_PNPM_IGNORED_BUILDS --- Ignored build scripts: xxx

之前一直好好的构建流程，怎么突然就不行了？我最近只改了业务代码，依赖没有变动，pnpm 配置也没动过------这报错从何而来？

第一次尝试

按照报错提示，我在本地项目中执行了 pnpm approve-builds，交互式地选中了提示的几个依赖包：

执行完毕后，自动生成了 pnpm-workspace.yaml 文件：

yaml 复制代码

onlyBuiltDependencies:
  - '@vue-office/docx'
  - core-js
  - esbuild
  - vue-demi

看起来挺合理的，我直接 commit 推上去，心想这下应该没问题了吧。

结果 Jenkins 一跑，报错一模一样。🤦

深入排查

既然本地没问题，那问题大概率出在 Jenkins 的运行环境上。我登录到 Jenkins 所部署的服务器，钻进 Docker 容器一看------果然发现了蹊跷：

Jenkins 环境中的 pnpm-workspace.yaml 内容和本地不一样，里面多了一段：

yaml 复制代码

allowBuilds:
  '@vue-office/docx': set this to true or false
  core-js: set this to true or false
  esbuild: set this to true or false
  vue-demi: set this to true or false
onlyBuiltDependencies:
  - '@vue-office/docx'
  - core-js
  - esbuild
  - vue-demi

关键区别在于：本地生成的配置用的是 onlyBuiltDependencies（v10 的配置格式），而 Jenkins 环境下 pnpm 额外注入了 allowBuilds 字段 ，而且值还是占位提示------没有真正设置为 true。

这说明 Jenkins 环境中的 pnpm 版本和本地不一致，对构建脚本的处理方式也不同。

根因定位

为什么只改了业务代码，Jenkins 构建就突然失败了？

直觉告诉我：这和 pnpm 版本升级有关。我直奔 GitHub 查看 pnpm 的 Release Notes：

github.com/pnpm/pnpm/r...

在 v11 的发布说明中，我一眼就看到了关键词 allowBuilds------构建脚本许可制，v11 的新安全特性：

再确认一下 Jenkins 环境中的 pnpm 版本：

果然是 v11！而我本地用的还是 v10。

再看 Jenkinsfile，发现它指定了 pnpm 的安装方式：

真相大白：Jenkins 环境在某次更新后安装了 pnpm v11，而本地仍在使用 v10。 v11 默认启用了 strictDepBuilds，要求所有包含构建脚本的依赖必须通过 allowBuilds 明确许可。我本地生成的 onlyBuiltDependencies 是 v10 的配置格式，在 v11 环境下不被识别为有效的许可声明，所以构建脚本依然被拦截。

最终解决

把 pnpm-workspace.yaml 中的配置改为 v11 的格式，将 allowBuilds 的值设为 true：

yaml 复制代码

allowBuilds:
  '@vue-office/docx': true
  core-js: true
  esbuild: true
  vue-demi: true

再次 commit，Jenkins 构建------终于成功了 ✅

反思

这次踩坑的根因并不复杂：本地和 CI 环境的 pnpm 版本不一致 。v11 在供应链安全方面做了多项默认启用的重要变更，其中 allowBuilds 就是最容易"迎面撞上"的那个。

几点教训：

本地和 CI 的工具链版本要保持同步。版本不一致是最常见的"本地能跑、CI 挂掉"的元凶。
关注依赖管理工具的版本升级公告。pnpm v11 这一波安全策略升级是"默认启用"的，不留神就会踩坑。
v10 的 onlyBuiltDependencies 在 v11 中已被 allowBuilds 统一替代，迁移时要注意配置格式的变化。

pnpm v11 的安全策略发力了，而我正好撞在了它的枪口上。不过话说回来，这些默认启用的安全机制（构建脚本许可、发布冷却期、非标准源拦截）确实在加固 npm 生态的供应链安全------只是作为开发者，我们得跟上节奏才行。