pnpm 11.3
pnpm 11.3 新增了对 npm 分阶段发布功能(pnpm stage)的支持;引入了全新的 trustLockfile 设置,用于跳过对已受信任的锁文件进行的供应链验证环节;此外,还提供了 pnpm pkg、pnpm repo 和 pnpm set-script 命令的原生实现。 此外,它为 pack 和 publish 命令新增了 --skip-manifest-obfuscation 标志,并降低了在大型工作区中执行 minimumReleaseAge 和 trustPolicy 验证时的内存占用。
次要更改
pnpm stage
全新的 pnpm stage 命令将 npm 的 分阶段发布 工作流引入了 pnpm。 分阶段发布功能允许你发布一个默认对 npm install 隐藏的版本,直至你明确予以批准——这对于验证发布产物、对 CI 进行烟雾测试,或协调多包发布流程都非常有用。
可用的子命令有:
pnpm stage publish # 发布一个版本至暂存区
pnpm stage list # 列出暂存区中的版本
pnpm stage view # 查看暂存区中的版本
pnpm stage approve # 将暂存版本提升至注册源
pnpm stage reject # 丢弃暂存版本
pnpm stage download # 下载暂存版本的 tarball 文件
trustLockfile
新增的 trustLockfile 设置用于控制 pnpm install 命令是否对已加载的锁文件中的每一个条目,重新执行 minimumReleaseAge / trustPolicy: 'no-downgrade' 检查。 当true时, 安装时将锁文件视为已经信任的文件,并跳过验证通过——对于每次提交都来自信任的作者的封闭源项目有用。 默认情况是 false,所以验证将保持默认状态。
在 pnpm-workspace.yaml 中设置它:
trustLockfile: true
此版本还降低了验证过程本身的内存占用:此前,针对每一组“注册表+包名"的信任元数据缓存会保留完整的套件信息——包括依赖关系图、脚本、README 以及各版本的清单文件——并将其贯穿整个安装过程。 在大型工作区(包含约 4000 个锁文件条目,且启用了 minimumReleaseAge 和 trustPolicy: no-downgrade)中,这可能导致堆内存上限为 2 GB 的 CI 运行器因内存不足而崩溃。 缓存现在仅存储信任检查实际读取的字段(即 time、各版本的 _npmUser.trustedPublisher 以及 dist.attestations.provenance);“精简元数据”缓存也进行了类似的裁剪,仅保留包级别的 modified 字段以及当前列出的版本名称集合。 修复 #11860。
原生的 pnpm pkg, pnpm repo 和 pnpm set-script
又有三个此前依赖 npm(或因缺失 npm 而无法使用)的命令,现已遵循 npm 命令惯例实现为原生命令:
pnpm pkg— 获取、设置或删除package.json中的字段。pnpm repo— 在浏览器中打开包的仓库地址。pnpm set-script(别名ss) — 在项目清单文件的scripts字段中添加或更新条目。 支持package.json、package.json5和package.yaml格式。
针对 pack 和 publish 的 --skip-manifest-obfuscation
针对 pnpm pack 和 pnpm publish 新增了 --skip-manifest-obfuscation 标志;使用该标志后,打包或发布的清单文件将保留原始的 packageManager 字段和发布生命周期脚本,而不会将其移除。 pnpm 专用的 pnpm 字段继续被省略。
补丁更改
- 修复了当已安装包的 CAS 槽位中缺少
package.json时,pnpm dlx报错ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND的问题。 在实际使用中观察到,当 GVS 插槽已填充,但缺少合成清单所要求的运行时归档时,会出现pnpm dlx node@runtime:<version>的情况。 当 slot 的清单无法读取时,dlx现在会回退使用不带作用域的包名——对于单二进制文件包(这是dlx的常见使用场景,包括所有runtime:类型的规范),这与manifest.bin指定的名称相一致。 - 修复了在启用
auto-install-peers且依赖图中包含互为传递性对等依赖的包(例如@aws-sdk/client-sts和@aws-sdk/client-sso-oidc)时,pnpm dedupe和pnpm install存在的非确定性行为。 在连续多次运行中,锁文件不再于两种同样有效的格式之间来回切换。 根本原因在于,resolveDependencies在由Promise.all触发的回调函数内部向其pkgAddresses或postponedResolutionsQueue数组中添加元素,导致任务完成的时序差异影响了数组的顺序,进而波及了后续的循环对等依赖后缀分配逻辑。 修复 #8155。 - 修复了一个回归问题:
pnpm add <github-shorthand>(以及任何无法从用户提供的规范中解析出别名的依赖项,例如 tarball URL 或pnpm/test-git-fetch#sha)在清单更新和pendingBuilds中被静默丢弃。 - 修复了
pnpm add --config导致pnpm-lock.env.yaml中残留孤立条目(即已更新配置依赖项的先前解析版本所包含的可选子依赖项)的问题。
