PNPM 11 适配 CNB 构建安全兼容方案

问题根因#

PNPM 11 进行了重大安全策略升级，默认开启两大防护机制，与无交互的 CNB 构建环境冲突，导致安装依赖失败

兼容方案#

在项目根目录 pnpm-workspace.yaml 中添加以下配置：

1
# 临时兼容CNB无交互构建：放开所有依赖构建脚本
2
dangerouslyAllowAllBuilds: true
3
# 临时关闭新版本包24小时冷却校验，适配私有包高频迭代
4
minimumReleaseAge: 0

• dangerouslyAllowAllBuilds: true：绕过脚本白名单机制，允许所有第三方依赖自动执行构建脚本，解决 CNB 交互阻塞报错
• minimumReleaseAge: 0：关闭包发布冷却安全策略，允许安装刚发布的新版私有包、开源依赖

长期安全方案#

摒弃高危全局降级配置，采用精准白名单+局部豁免机制，保留 PNPM 核心安全能力，同时适配 CNB 构建

操作步骤:

1. 本地有交互终端执行，自动生成可信脚本白名单 pnpm approve-builds 按需授权项目所需的构建依赖（如 esbuild、sharp、@parcel/watcher 等），自动写入配置文件

2. 私有包豁免冷却校验：不全局关闭冷却，仅放行内部可信包

3. 提交更新后的 pnpm-workspace.yaml 到代码仓库，CNB 直接无感知构建

最终安全配置模板

1
# 开启严格脚本校验（保留安全能力）
2
strictDepBuilds: true
3
# 仅放行项目可信的带构建脚本依赖（精准白名单）
4
allowBuilds:
5
  esbuild: true
6
  sharp: true
7
  @parcel/watcher: true
8

9
# 保留公共包24小时冷却防护
10
minimumReleaseAge: 1440
11
# 仅内部私有包豁免冷却，适配高频迭代
12
minimumReleaseAgeExclude:
13
  - "@你的组织/*"

CNB 构建命令规范#

无论临时方案还是安全方案，CNB 流水线统一使用安全构建命令，杜绝版本浮动风险：

1
# 锁定锁文件，禁止自动更新依赖版本
2
pnpm install --frozen-lockfile

同时在项目 package.json 锁定 PNPM 版本，避免环境策略不一致：

1
{
2
  "packageManager": "pnpm@11.4.0"
3
}