Node.js 社区关于默认启用 Corepack 和可能拆分 npm 的争论愈演愈烈

Node.js 社区正在“就 2023 年 11 月提出的默认启用 Corepack 的建议”展开激烈的讨论。这引发了 npm 是否将通过 Corepack 提供的问题，因为一些贡献者认为，整合 Corepack 的最终目的是使 Node.js 发布与 npm 发布脱钩。

Corepack 允许开发人员在无需安装 Yarn、npm 和 pnpm 的情况下使用它们。虽然 Corepack 已经默认随所有最新的 Node.js 版本一起发布，但开发人员仍需运行 corepack enable 来安装所需的 Yarn 和 pnpm 二进制文件。

支持启用 Corepack 的人认为，这将简化软件包管理器的版本管理，从而简化开发体验。他们还认为，默认启用 Corepack 将为其他软件包管理器提供更公平的竞争环境，从而有可能摆脱 npm 目前的主导地位，让其他软件包管理器获得更广泛的采用。

npm 坚决反对通过 Corepack 分销

Myles Borins 评论:

我支持取消对 corepack 的标记，也支持任何想要集成的软件包管理器。由于种种原因，npm 并不想集成，我们也不想被迫支持这种模式。

我不会阻止其他软件包管理器在 Node.js 中默认启用 corepack，但我反对将其用于 npm，也反对默认开启任何形式的 npm 支持。我的要求是，如果默认启用 corepack，则 npm 支持应保留在一个额外的标志或命令后面，供开发者选择。如果开发者想要一个包含 corepack 的流程，我个人认为他们应该选择另一个为使用这种模式而开发和设计的软件包管理器，比如 yarn。这就是工具生态系统的魅力所在，我认为 npm 不应该被强迫使用一种它没有设计好的模式。

Borins 还列举了 Corepack 发布 npm 时存在的一些技术问题，并在详细的评论中进行了阐述：

• 跳线模式引入了额外的间接性/不清楚使用的是哪个版本的软件包管理器以及在磁盘上的哪个位置
• 将软件包管理器固定在项目级别可能会导致安全漏洞的暴露
• 缺乏对节点 + 软件包管理器版本的明确测试，无法更新软件包管理器版本
• Corepack 中硬编码的软件包管理器版本会增加更新工作量
• 必须通过网络动态安装软件包管理器才能启动
• 在增加额外工作的同时，对 npm 缺乏明确的益处

如果默认启用 Corepack 会改变 npm 与 Node.js 的分布方式，那么这种改变将违背 npm 团队的意愿，因为 Borins 认为这种改变 "会带来更多的复杂性和不一致性，却不会明显改善现状"。

Node.js技术指导委员会讨论启用Corepack作为从Node.js二进制文件中移除npm的途径

在 1 月 10 日举行的 Node.js 技术指导委员会 (TSC) 会议上讨论了以下问题

如果目标不是从 Node.js 二进制中移除 npm，那么添加 Corepack 是否有意义？启用 Corepack 的主要动机是否是为了消除人们对 npm 历史上默认捆绑的不公平感？还是为了改善那些使用不那么流行的软件包管理器的开发者的体验？

TSC 成员亚吉兹-尼兹普利（Yagiz Nizipli）是将 npm 从 Node.js 中分离出来的最积极支持者之一，他建议委员会要么移除 npm，要么捆绑其他软件包管理器。他认为，这种模棱两可的情况正在制造不必要的摩擦。

Nizipli 认为，Node.js 应关注捆绑的规模，并考虑 npm 相对于其他软件包管理器的战略优势。他对用户为了安装和使用其他软件包管理器而被迫安装 npm 感到不满。如果不启用 Corepack，就无法将 npm 作为 Node.js 二进制的一个依赖项删除。

npm 在 Node 生态系统前所未有的成功中所扮演的角色

其他 TSC 成员认为，npm 与 Node.js 一起发布是生态系统成功的关键部分。

出席会议的 Matteo Collina 说，默认提供软件包管理器是 Node 蓬勃发展的关键因素之一，他认为没有充分的技术理由将 npm 迁移出去。发布 npm 的主要优势之一是构建的稳定性。

"Collina 说："如果你安装了一个 Node 版本，你就能绝对清楚地知道你将获得的 npm 版本，你就能有一个清晰的构建。"如果你使用 Corepack，你就不会有明确的构建。这对生态系统中的维护者来说是个定时炸弹。

Collina 建议，争议最少的方法是启用 Corepack，并从 Corepack 中移除对 npm 的支持，这样 npm 团队就不会被迫通过他们认为在技术上不可取的方法发布软件包管理器。他还建议将拆分 npm 的议题分离出来。

与会的其他人认为，如果不引入大规模的破坏性改动并造成大量沮丧的用户，就不可能移除 npm。

TSC 成员提出的另一个问题是，Corepack 的使用范围是否足以支持 Node 生态系统--开发人员是否知道它是什么？委员会一致认为，他们尚未充分了解这一拟议变更的影响，并预计它可能会造成严重的破坏。

解除 npm 存在争议，难以达成共识：TSC 将付诸表决

在大多数项目内部决策中，TSC 都会采用寻求共识的决策模式。在这种情况下，委员会认为此事争议太大，意见分歧太大，无法达成共识。无论如何讨论，都不会有明显的解决办法。他们一致认为，应将此事付诸表决，以确定他们对以下问题的答案：

• 我们同意我们的目标是从 Node.js 中移除 npm：是/否
• 如果我们不打算移除 npm，那么 corepack 是否应该包含在 Node.js 中：是/否
• 我们今天是否应该默认启用 corepack？是/否

TSC 成员 Geoffrey Booth 建议，无论谁想支持移除 npm，都应在付诸表决前撰写一份单独的提案。他说此事并不紧急，预计最早也要到 2024 年 4 月才会发生。在过去的几次会议中，该议题一直未列入议程。

两周前，Booth 建议感兴趣的利益相关者在 PR 中整理自己的想法，说明 Node.js 在捆绑包管理器方面的技术优先级：

我认为 TSC 再次讨论 Corepack 问题的时机还不成熟。该主题上有多人主张启动新的主题，尝试就各种开放问题达成共识；我建议针对 https://github.com/nodejs/node/blob/main/doc/contributing/technical-priorities.md 启动 PR，尝试确定我们打算实现哪些目标，然后再讨论第二个问题，即选择实现这些目标的最佳方式。我在想，这些公关可以成为组织我们需要进行的讨论的一种方式；或者，人们也可以提出比当前问题范围更广的新问题。无论如何，还有很多很多问题没有解决，我认为 TSC 还没有准备好做出任何决定。

与此同时，GitHub 上的讨论仍在继续，最初的问题已有 100 条评论，这些评论来自对结果感兴趣的人们。

"Borins 在该主题上评论道："我 100% 支持我们所能做的一切，让客户端访问更容易，减少入门步骤，让体验更好，让竞争更公平。"我不支持强迫不想使用 Corepack 的团队采用它。他代表 npm 重申了自己的立场：

• 让 pnpm + yarn 以他们想要的方式使用吧
• 如果可以的话，让我们取消对 corepack 的标记吧
• 请不要强迫 npm 使用 corepack
• 如果您想深入研究未捆绑的 npm，请分开讨论

最终，Node.js 技术指导委员会将在进行更多探讨和讨论后做出决定。如果 Corepack 的使用率像某些人猜测的那样低，委员会是否会有胆量默认启用 Corepack 并违背团队意愿松绑 npm？这似乎不太可能，但仍是一个值得讨论的话题。

"Node.js 的合作者 Antoine du Hamel 评论说："我不认为将 Yarn 和 PNPM 像 npm 一样销售到 Node.js 中是一个现实的选择（更多的安全问题、更大的捆绑规模，而且很可能与我们的 LTS 政策不符）。

"我也不认为讨论解绑 npm 有什么意义，因为这会对生态系统造成影响。如果发布团队希望这样做（我认为他们更有可能受到这一决定的影响），我们可以讨论一下，但走这条路似乎没有什么成效。(这就好比 Node.js 和 npm 互相叫板，直到有一个项目屈服，或者大家都输掉）"。

为什么 Node.js 附带软件包管理器？

npm 的发明者和创始人 Isaac Schlueter 加入了 GitHub 上的讨论，并就 Node.js 为何要配备软件包管理器提供了一些历史背景：

尽管我看到了一些阴谋论的说法，但让 npm 与 node 捆绑并不存在什么见不得人的幕后交易。Ryan 和我发现，用户在尝试启动和运行 node 项目时经常受挫，没有软件包管理器就无能为力，因此我们开始将 npm 与 node 一起发布。当时还没有其他替代方案，而且 npm 也得到了 node 核心团队成员的支持，因此它是不二之选。它是公开讨论过的，没有争议；人们需要它，所以我们给了他们，就是这样。

他认为，为软件包管理器提供公平竞争的环境不应是 Node 关心的问题，并鼓励社区研究 Corepack 是否是解决 Node 问题的最佳方案。

"不同的开放源码软件项目获得不同程度的曝光和分发，那又怎样？Schlueter 说。"这似乎不是 Node 的问题。Node 关心的应该是 Node 用户的体验和他们使用 Node 的成功，而不是某个软件包管理器是否在'市场'中占有'公平'的份额（在'市场'中，没有人付费，'赢家'得到的回报只是成本）。Node 是否应该包含替代的 JS 引擎或 TLS 实现，因为它 "不公平地 "享有 V8 和 OpenSSL 的特权？对于这样的问题，'公平'是一个荒谬的标准"。

是时候让 Node 正式确立与软件包管理器的关系了

对现状的任何重大改变都需要经过充分论证，因为对 Node.js 生态系统和开发工作流程的长期影响可能会永远改变，从而无法促进相同水平的创新和社区参与。Node.js 作为一个成熟度如此之高的项目，是时候以一种明确的方式正式确定其与软件包管理器的关系，并将这种关系根植于其技术优先级中。

"除此以外，即使在这个主题中，问题的关键也被搁置了：Node.js 与构建和运行项目所需的各种附加工具之间的正式关系应该是什么？Wes Todd 评论道。"Wes Todd 评论说："当人们询问 Corepack 中包含的工具应满足哪些要求，或者如何审核和决定时，并没有一个明确的答案。

在改变 JavaScript 包管理器的未来之前，这些都是需要回答的重要问题。在 Node 社区继续就这些热门话题展开讨论之际，Todd 鼓励参与讨论的人员认识到 npm 对生态系统的馈赠。

"是的，我知道 npm 在这一问题上存在争议，因为它在成为盈利实体之前就被捆绑在一起了；是的，我知道我们发布和安装的注册表是这一交易的一部分，这从根本上就存在问题。

"但这并不能改变一个事实，那就是由于这些人的努力，我们今天才能在这里拥有世界上最大的软件平台和受众。即使在前进的道路上磕磕绊绊，npm 的员工们还是为这个生态系统献上了一份厚礼，他们比我们中的大多数人都更尽职尽责。现在是抛开历史，讨论什么对 Node.js、其维护者、用户和整个 JS 生态系统最有利的时候了。

原文来自：https://socket.dev/blog/node-community-debates-enabling-corepack-unbundling-npm

链接: https://www.fly63.com/article/detial/12659