大家好，这里是大家的林语冰。
Node 社区正在认真考虑默认启动 Corepack 的决定，这引发了关于从 Node 二进制文件中删除 npm 的可能性的争论。
免责声明
本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 Node.js Community Debate Intensifies。
Node 社区正在就 2023 年 11 月提出的默认启动 Corepack 的提案百家争鸣。这引发了未来是否会通过 Corepack 捆绑提供 npm 的问题，因为某些贡献者认为最终其集成的目标是分离 Node 版本和 npm 版本。
Corepack 允许开发者使用 yarn、npm 和 pnpm，而无需安装它们。尽管 Corepack 已默认随所有最新 Node 版本一起分发，但开发者仍然必须运行 corepack enable，安装所需的 yarn 和 pnpm 二进制文件。
Corepack 支持者认为，它将通过简化包管理器的版本管理，从而简化开发体验。Corepack 支持者还认为，默认启动 Corepack 将为包管理器竞品提供更公平的竞争环境，有可能改变 npm 目前的霸主地位，并允许其他包管理器获得更广泛的采用。
npm 坚决反对通过 Corepack 分发
npm 代表方发表评论，明确表示 npm 反对通过 Corepack 进行分发：
"老子支持 unflashing corepack 和任何想要集成的包管理器。由于各种原因，npm 不希望集成，我们也不希望被迫支持这种模式。
我不会阻止任何在 Node 中为其他包管理器默认启动 corepack 的工作，但我确实反对将其用于 npm 以及默认启动的任何类型的 npm 支持。我的要求是，如果默认启动 corepack，那么 npm 支持保留在开发者选用的附加标志或命令后面。如果开发者想要一个包含 corepack 的流程，私以为它们应该选择为使用此模式而开发和设计的不同包管理器，比如 pnpm。这就是拥有工具生态系统的美妙之处，私以为 npm 不应该被迫使用它不适合使用的模式。"
npm 代表方还列举了 Corepack 分发 npm 的若干技术难题：
- 跳线模式（jumper pattern）引入了额外的间接性/不清楚正在使用的包管理器版本以及磁盘上的位置
- 将包管理器固定在项目级别可能会导致暴露于安全漏洞
- 缺乏对 Node + 包管理器版本的明确测试来更新包管理器版本
- Corepack 中包管理器的硬编码版本增加了更新工作量
- 必须通过网络动态安装包管理器才能开始
- 在增加额外工作的同时，npm 缺乏明显的好处
如果默认启动 Corepack 会改变 npm 与 Node 的分发方式，那么这种改变将违背 npm 团队的意愿，因为它会引入 npm 代表方所说的"更加复杂和不一致，而不会显着改善现状"。
Node 技术指导委员会讨论启用 Corepack 作为从 Node 二进制文件中删除 npm 的途径
在 1 月 10 日的 Node TSC（技术指导委员会）会议上，TSC 成员详细讨论了该问题，但并未明确该提案的目标。
问题仍然在于，如果目标不是从 Node 二进制文件中删除 npm，那么添加 Corepack 是否有意义。启动 Corepack 的主要动机是为了解决 npm 在默认打包历史上的垄断地位所带来的不公竞争问题吗？或者目标是改善那些使用人气一般的包管理器的开发者的体验？
TSC 某位成员是将 npm 从 Node 中分拆出来的最有力支持者之一，建议委员会删除 npm 或捆绑其他包管理器。该成员表示，这种现状的模糊性正在造成不必要的阻力。
npm 反对者认为 Node 应该关注包的大小，并考虑 npm 相对于其他包管理器的战略优势。它对用户被迫安装 npm 以安装和使用包管理器竞品感到不满。如果不启动 Corepack，就无法删除 npm 作为 Node 二进制文件的依赖。
npm 在 Node 生态系统空前成功中的作用
其他 TSC 成员认为，npm 与 Node 一起发布是生态系统成功的关键部分。
出席会议的 npm 支持者表示，默认提供包管理器是 Node 人气爆棚的关键因素之一，它认为没有很好的技术理由来迁移 npm。交付 npm 的主要优点之一是构建的稳定性。
"如果你安装 Node 版本，你就可以绝对清楚你将获得的 npm 版本，并且可以有一个清晰的构建，"npm 支持者说道。"如果你使用 Corepack，你就不会没有清晰的版本构建。这对于生态系统的维护者而言是一颗定时炸弹。"
npm 支持者建议，争议最少的方案是启用 Corepack，并从 Corepack 中删除 npm 支持，这样 npm 团队就不会被迫通过它们认为技术上令人反感的方法来分发包管理器。它还建议将分解 npm 的主题分开。
其他出席会议的成员认为，在不引入大规模破坏性更改并造成大量沮丧用户的情况下，不可能删除 npm。
TSC 成员提出的另一个考虑因素是 Corepack 是否得到广泛使用，从而支持 Node 生态系统 ------ 开发者是否知道它是什么？委员会一致认为，它们尚未完全了解这一拟议变更的影响，并预计它可能会造成严重破坏。
拆分 npm 争议太大，无法达成共识：TSC 将对其进行投票
在大多数情况下，对于内部项目决策，TSC 在寻求共识的决策模式下运作。在这种情况下，委员会一致认为，此事争议太大，意见太过分歧，无法达成共识。再多的讨论也不会得出明显的解决方案。它们同意应该进行投票以确定以下问题的答案：
- 我们同意我们的目标是从 Node 中删除 npm：Yes/No
- 如果我们不打算删除 npm，corepack 是否应该包含在 Node 中：Yes/No
- 今天我们是否应该默认启动 corepack：Yes/No
TSC 某位成员建议，无论谁想要支持删除 npm，都应该在进行投票之前编写一份单独的提案。它表示此事并不紧急，预计最早会在 2024 年 4 月发生。最近几次会议都没有提上这个话题。
两周前，有成员建议感兴趣的利益相关者在 PR 中组织它们的想法，解决 Node 在捆绑包管理器方面的技术优先事项：
"私以为 TSC 再次讨论 Corepack 问题的时机还不成熟。该线程中的多个人主张启动新线程，以尝试就各种悬而未决的问题达成共识；我建议在继续第二个目标之前，尝试确定我们打算实现的目标选择实现这些目标的最佳方式的问题。我认为这些 PR 可能是组织我们需要进行的讨论的一种方式；或者大家可以提出比当前问题范围更广的新问题。无论如何，还有太多悬而未决的问题，私以为这还不足以让 TSC 做出任何决定。"
与此同时，GitHub 上的讨论仍在继续，最初的问题有 100 条来自参与该结果的社区评论。
"老子百分百支持我们可以采取的一切措施，让客户访问更容易、减少入门步骤、改善体验以及公平竞争环境。"某位用户在该帖子中评论道。"老子不支持强迫不想使用 Corepack 的团队采用它。"它代表 npm 重申了自己的立场：
- 让我们按照 pnpm + yarn 想要的消费方式来运送它们
- 如果可以的话，让我们取消 corepack 的标记
- 请不要强制 npm 使用 corepack
- 如果您想深入了解非捆绑的 npm，请分开讨论
最终，Node 技术指导委员会将在更多探索和讨论后做出决定。如果 Corepack 的使用率被证明像某些用户怀疑的那样微不足道，那么委员会是否会鲁莽地默认启动它，并违背团队的意愿取消 npm 的捆绑？这似乎不太可能，但这仍然是一个讨论的话题。
Node 某位合作者评论道："私以为像 npm 这样将 yarn 和 pnpm 供应到 Node 中并不是一个现实的选择，更多安全问题，更多包大小，并且可能不太符合我们的 LTS 政策"。
"由于生态系统的影响，私以为讨论分拆 npm 也意义不大。如果发布团队希望这种情况发生，私以为它们是最有可能受到该决定影响的群体，我们可以讨论它，但走这条路似乎效率不高。这就像 Node 和 npm 互相虚张声势，直到一个项目崩溃，或者所有人都输了。"
为什么 Node 附带了包管理器
"npm 之父"加入了 GitHub 上的讨论，提供了某些有关 Node 为何附带包管理器的历史背景：
"尽管我见过阴谋论声称并非如此，但并没有任何不正当的幕后交易将 npm 与 Node 捆绑在一起。老子和"Node 之父"发现用户在尝试启动和运行 Node 项目时不断受到阻碍，并且如果没有包管理器就无法做很多事情，因此我们开始将 npm 与 Node 一起提供。当时没有其他选择，而且有核心 Node 团队成员支持，所以这是显而易见的选择。这是公开讨论的，没有争议；大家都需要它，所以我们提供服务，仅此而已。"
它认为 Node 不应该关心包管理器的公平竞争环境，并鼓励社区检查 Corepack 是否是解决 Node 问题的最佳解决方案。
"不同的 OSS 项目获得不同程度的曝光和分发，那又怎样呢？""npm 之父"讲道，"这看起来并不是 Node 的问题。Node 应该关心 Node 用户的体验，以及它们使用 Node 的成功，而不是任何给定的包管理器是否拥有'市场'的'公平'部分，一个没有人付费且'获胜者'获得奖励的'市场'，除了成本，啥也没有。Node 是否应该包含替代的 JS 引擎或 TLS 实现，因为它'不公平'地赋予了 V8 和 OpenSSL 特权？对于这样的问题，'公平'是一个荒谬的标准。"
是时候让 Node 正式确定其与包管理器的关系了
对现状的任何重大改变都需要得到充分证实，因为对 Node 生态系统和开发工作流程的长期影响可能会永远改变，而这种改变可能无法促进同等水平的创新和社区参与。作为一个项目，在这个成熟度级别上，Node 是时候以一种根植于其技术优先级的明确方式正式确定其与包管理器的关系了。
"除此之外，即使在这个帖子中，问题的症结仍然是：Node 与构建和运行项目所需的各种附加工具之间的正式关系应该是什么？当大家询问 Corepack 中包含的工具应该满足哪些要求，或者如何审查和决定它时，没有明确的答案。"
在改变 JS 包管理器的未来之前，这些是需要回答的重要问题。随着 Node 社区继续讨论这些热门话题，我们鼓励讨论参与者认识到 npm 给生态系统带来的礼物。
"是的，我知道 npm 在这方面有争议，因为它在成为盈利实体之前就被捆绑了，是的，我知道我们发布和安装的注册表是该交易的一部分，这从根本上是有问题的。"
"这并没有改变这样一个事实：由于这些人的工作，我们今天聚集在一起，拥有世界上最大的软件平台和受众之一。即使道路上充满坎坷，从事 npm 工作的成员也给了这个生态系统一份礼物，并且比我们大多数人更好地履行了自己的责任。现在是时候把这段历史放在一边，讨论什么对 Node、它的维护者、它的用户，以及整个 JS 生态系统来说是最好的了。"
本期话题是 ------ 你认为 npm 应该和 Node 解绑吗？你支持 corepack 的捆绑方案吗？
欢迎在本文下方自由言论，文明共享。谢谢大家的点赞，掰掰~
《前端猫猫教》每日 9 点半更新，坚持阅读，自律打卡，每天一次，进步一点。
