Node.js 技术委员会：不会在发行版本中删除 NPM！
Node.js 技术委员会：不会在发行版本中删除 NPM！
在之前的文章中，我们提到 Node.js 社区在关于默认开启 Corepack 的提案中引发了激烈的争论，也间接引发了大家对是否在 Node.js 版本中移除 NPM 的讨论：
抛弃 NPM ？Node.js 社区正为启用新的包管理方式争论不休！
Node.js 技术指导委员会（TSC）本周为此专门举行了会议，并且做出了一些关键决定。出席的成员确认他们已经达成了一致意见，即没有意图在 Node.js 中删除 npm。
之前围绕 Corepack 的讨论提出了一个问题，即是否会将 npm 通过 Corepack 提供，因为一些贡献者认为，从 Node.js 移除 npm 是集成 Corepack 的最终目标。
由 TSC 成员 Geoffrey Booth 开启的一个 PR 上周已经合并，明确了这一共识。其中声明，移除 npm 并不是项目的目标：
作为解决在2024年1月24日会议的
TSC成员的一部分，此PR的目的是帮助澄清Corepack的目标：从Node.js分发中移除npm并不是最终目标。
这也算整理了 #50963 (comment) 中所写的内容 ，这似乎是一个共识：
我们确保了与
npm客户端的 “特殊关系”，明确声明它是npm仓库的参考实现，也是出于历史原因。
这个 PR 更新了 Node.js 的技术优先级文档，增加了新的包管理部分：
轻松安装和管理依赖项以及开发工具的能力是用户体验的关键部分，因此
Node.js必须作为其分发的一部分提供包管理器。Node.js为此目的而包含npm。这是出于历史原因 —— 当npm在 2011 年被添加时，它是唯一的 JavaScript 包管理器 —— 并且因为它是npm仓库的参考实现，这是大多数 JavaScript 软件的事实上的主要来源。根据我们的政策，不包含多个服务相同目的的依赖项或工具，Node.js项目不包含任何其他包管理器；虽然它可能包含其他软件以下载其他包管理器。
此 PR 遵循了 TSC 在2024年1月24日的会议，该会议试图澄清 Corepack 在 Node.js 生态系统中的目标。它确认，无论为了启用 Corepack 而讨论了什么想法，移除 npm 都不是 Node.js 项目的目标。
TSC 成员代表了多元的观点和利益，但这个 PR 也有一些反对的声音
“从长远来看，应该将解绑
npm作为目标。”TSC成员 Yagiz Nizipli 这样说。
但是最终，大多数成员赞成暂时取消删除 npm 的问题。
代表 npm 的 TSC 成员 Myles Borins 强烈建议贡献者从一个实用的立场来考虑这个问题 - “Node.js 是否应该带着一个包管理器进行分发” - 。他还鼓励参与讨论的人搁置争论，并围绕这个架构决定寻找共识：
如果可能的话，我也很想停止关于是否分拆 npm 的争论。我承认我在这里存在偏见和利益冲突。需要明确的是，我认为单独发表这一声明是有问题的，因为它过度简化了复杂的问题空间。让我们明确目标和原因。如果没有明确的解决方案来取代它，简单地解绑 npm 会让 Node.js 变得更糟。如果目标是“仅动态获取包管理器”或“通过 corepack 分发所有包管理器”，那么目标就少了很多。简单地说“我们的目标是解除 npm 的捆绑”会给那些为支持 Node.js 项目和 JavaScript 生态系统做出大量努力、独立于公司隶属关系的开发团队产生极大的敌意。如果您的目标是“仅独立或中立维护的包管理器”，请指出这一点，到目前为止，还没有明确说明这一点。让我们有目标和解决方案，而不是问题和其他东西。
Booth 最近还提交了另一个 PR，增加了一个 Node.js 分发策略文档，其中声明该项目“包括一些 Node.js 项目不维护的外部软件”。它也重申了项目对于 JavaScript 生态系统竞争的支持：
选择包含特定的软件并不意味着这个软件相对于其竞争者有任何特殊之处；在某些情况下，软件是在没有竞争者的情况下被添加的。虽然
Node.js项目支持并鼓励在 JavaScript 生态系统中的竞争，但作为一个策略，Node.js项目不包含多个服务同一目的的依赖项或工具。
这个 PR 的目标是集中针对 Corepack 的决策制定，去除一些未知因素，并记录在各个与 Corepack 相关的线程中形成的共识。
在本周的会议中，TSC 成员就默认启用 Corepack 的讨论取得了一些进展，但同意无需着急决定 Node.js 22 的决定。
贡献者目前另外也正在讨论一个 “占位符” 可执行文件的策略，考虑 Node.js 是否会安装在 Node.js 之外启用二进制文件、脚本等的链接。问题之一是占位符是否会让 Node.js 因占位符中包含的任何安全问题而陷入困境。
“即使我们在某处有一些细则，表示在我们的
yarn命令下载和安装的Yarn软件中的任何漏洞，我们并不负责，我认为许多用户会理解地认为这并不能使我们免责：我们应该为Yarn提供与我们为npm提供的相同的安全保障，即使Yarn实际上并未在我们的分发中打包，” Booth 在PR中说。
TSC 打算在下周对占位符可执行文件进行更多讨论，作为 Corepack 决策的一部分。在本周的会议上，Booth 鼓励与会者不要对措辞过于挑剔，而应该进一步决定 Node.js 是否允许占位符或仅允许包管理器使用占位符。如果允许的话，Node.js 是否必须对它们负责？该项目的成本是多少？这一决定可以有多种方式进行。
Corepack 的讨论还在进行中，感兴趣大家可以阅读下面两个 PR：
- 默认启用 Yarn 和 pnpm Corepack 二进制文件：https://github.com/nodejs/node/pull/51886
- 默认启用 Corepack 的替代方案：https://github.com/nodejs/node/issues/51931
Corepack 的引入确实会对当前的 Node.js 生态带来很大的影响，对此大家怎么看？