pnpm 11 候选版本发布，带来 ESM 分发、供应链默认设置以及新的存储格式
pnpm（高效且节省磁盘空间的 JavaScript 包管理器）发布了 pnpm 11 RC 版本。这次更新带来了多项重大改进，涵盖了性能、供应链安全以及更小、更严格的配置系统等。 pnpm 11 RC 版本的新特性包括：新增一个基于 SQLite 的存储索引；默认启用供应链保护功能；通过全局虚拟存储实现隔离的全局安装操作；统一的 其中一项主要的变更是，pnpm 现在以纯 ESM 的形式发布，并要求使用 Node.js v22 或更高版本，同时完全停止对 Node.js 18、19、20 和 21 的支持。安装文档已经更新，其中提供了兼容性对照表。 该版本还对默认的安全设置进行了增强， 构建脚本设置经过了整合， 全局安装现在已经实现有效隔离，每个通过 开发人员可以通过以下命令试用这个版本： 迁移指南收录在pnpm 11.x 文档以及v11 跟踪讨论中。 在Hacker News上，在一个关于近期安全漏洞的讨论帖中，有一位评论者明确推荐使用 pnpm 而不是 npm，并且说“ PNPM 10.x 封堵了其中许多攻击途径，而 NPM 安全性太差，不适合在生产环境中作为命令行工具使用”。不过也有人对此提出异议，认为“ NPM 从来都不算太不安全，至今也依然如此”。 那些本该受益于冷却期的人，根本就不会去查看更新。如果没有冷却期，他们也会像其他受害者一样成为恶意软件的受害者。 而其他评论者则警告说： 世上没有免费的午餐。推迟发布不仅会延缓攻击，也会延缓关键的安全补丁发布。这没有放之四海皆准的策略，无论哪种方式，你都会面临风险。 与 npm 和 Yarn 相比，pnpm 11 不仅保留了其一贯的优势——默认隔离的 pnpm 是一款开源的 JavaScript 包管理器，其最知名的特点是安装速度快，能够通过内容可寻址存储和使用符号链接的 声明：本文为 InfoQ 翻译，未经许可禁止转载。 allowBuilds设置；一系列新命令，包括：pnpm ci、 pnpm sbom、 pnpm clean、 pnpm peers check和 pnpm runtime set，同时还提供了简短的别名pn和pnx。minimumReleaseAge设置现在默认为 1 天，也就是说，新发布的版本 24 小时内不会被解析，blockExoticSubdeps默认为 true。此举源于 npm 生态系统中数月来频繁发生的重大供应链安全事件。在 Hacker News 上，评论者们就“宽限期是否切实有助于检测”这一问题展开了辩论。onlyBuiltDependencies、 onlyBuiltDependenciesFile、 neverBuiltDependencies、 ignoredBuiltDependencies和 ignoreDepScripts 都已经移除，取而代之的是一个 allowBuilds 选项， strictDepBuilds 现在默认是 true 。此外， pnpm 不再从 package.json的"pnpm"字段和npm_config_ 环境变量中读取配置了，全局配置文件已经改为 YAML 文件，allowNonAppliedPatches、 ignorePatchFailures、 pnpm server和 useNodeVersion 都已经移除。pnpm add -g安装的包都会有独立的目录、package.json、node_modules及锁定文件；此外，全局虚拟存储对于pnpm dlx和全局包默认启用，但在普通项目中仍然需要手动启用。性能优化工作包括：迁移至 undici 并采用 Happy Eyeballs 优化 HTTP 性能、跳过暂存目录直接写入存储、预分配 tarball 下载，以及 NDJSON 元数据缓存。pnpm self-update next-11minimumReleaseAge的默认设置一直备受关注，也被称为“依赖冷却期”。Hacker News 上一个关于依赖冷却期的讨论帖引发了更多关于该话题的争论，其中一位评论者指出：node_modules、内容可寻址存储以及对单存储库（monorepo）的一等支持——还提供通过pnpm sbom生成 SBOM 的功能以及更严格的构建脚本处理，这进一步巩固了其在安全性方面的领先地位，而这些正是Yarn 目前仍然无法匹敌的领域。node_modules实现高效的磁盘使用。它在前端和后端生态系统中均有广泛的应用，并与 npm、Yarn 和 Bun 直接竞争。