抛弃 NPM ？ Node.js 社区正为启用新的包管理方式争论不休！

ConardLi

发布于 2024-03-02 08:32:29

1940

发布于 2024-03-02 08:32:29

文章被收录于专栏：code秘密花园

在 Node.js 社区中，关于默认开启 Corepack 的提议引发了激烈的争论，我在文末也发了个投票想看看大家的想法。

这项提议最早于 2023 年 11 月提出：

而这又引发了其他的一系列问题：未来是否会由 Corepack 提供 npm ？一部分贡献者认为，集成 Corepack 的终极目标应该是使 Node.js 和 npm 的发布过程解耦。

Corepack 能让开发者无需手动安装，就能使用 Yarn、npm 和 pnpm。尽管所有近期的 Node.js 版本都已默认集成 Corepack，但开发者仍需执行 corepack enable 命令来安装使用 Yarn 和 pnpm 所需的二进制文件。

主张默认启用 Corepack 的人士认为，这将简化包管理器的版本管理，进而优化开发体验。他们还坚信，将 Corepack 作为默认设置，为其他包管理器提供了一个公平的竞争环境，这可能引发 npm 当前的主导地位被动摇，使其他的包管理器有更多的采用机会。

npm 坚决反对默认启用 Corepack

Myles Borins 代表 npm 发表评论，明确表示 npm 反对通过 Corepack 进行分发：

我支持解除对 corepack 以及任何愿意整合的包管理器的限制。然而，由于种种原因，npm 并不希望进行这样的整合，我们不希望被迫支持这种模式。
我不会阻止在 Node.js 中默认启用 corepack 来适应其他的包管理器，但我确实反对用它来做 npm，也反对任何默认启用的 npm 支持。我希望，如果默认启用 corepack，那么对 npm 的支持应该通过额外的标志或命令进行，供开发者选择是否接受。如果开发者希望使用包含 corepack 的流程，我个人认为他们应该选择一个专门用来应对这种模式的不同的包管理器，比如 yarn。拥有一个生态系统的工具是一种挺好的事情，我不认为 npm 应被迫使用一个它本不打算采用的模式。”

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

在项目级别定死包管理器可能导致暴露出安全漏洞
缺乏清晰的测试 node 和包管理器版本以更新包管理器版本
在 Corepack 中为包管理器硬编码版本，这增加了更新的工作量
必须通过网络动态安装包管理器才能开始工作
对于 npm 来说，看不清楚的收益，却要做额外的工作

如果默认启用 Corepack 改变了 npm 与 Node.js 的分发方式，这个改变将违背 npm 团队的意愿，因为 Borins 认为这种改变 “增加了更多的复杂性和不一致性，却没有显著改善现状。”

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

在 1 月 10 日的 Node.js 技术指导委员会（TSC）会议上，TSC 成员们详细讨论了这个问题，但对提议的目标没有明确的认识。

问题仍然是，如果目标不是从 Node.js 二进制文件中移除 npm，那么是否有必要添加 Corepack？启用 Corepack 的主要动机是否是为了解决 npm 历史上默认绑定的不公平现象？还是为了改善那些使用不太流行的包管理器的开发者的体验？

TSC 成员 Yagiz Nizipli，是一个赞成从 Node.js 中解捆绑 npm 的有力倡导者，他建议委员会应该选择移除 npm，或者捆绑更多的包管理器。他认为，这种情况的不确定性正在造成不必要的摩擦。

Nizipli 认为，Node.js 应当关注默认捆绑包的大小，并考虑 npm 相对于其他包管理器的战略优势。他对用户为了安装并使用其他的包管理器，而被迫安装 npm 感到不满。如果不启用 Corepack，就没有从 Node.js 二进制文件的依赖项中移除 npm 的途径。

npm 在 Node.js 生态系统取得成功发挥的作用

其他 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，Node.js 中是否应该包含 Corepack：是/否
我们今天是否应默认启用 Corepack：是/否

TSC 成员 Geoffrey Booth 建议，希望提倡从 Node.js 中移除 npm 的人在投票之前应写一个单独的提议。他表示这个问题并不紧迫，预计任何事情最早也可能会在 2024 年 4 月发生。在过去的几次会议上，这个议题都未上议程。

几周前，Booth 建议对此感兴趣的利益相关者整理出他们的想法，通过 PR（Pull Request）来解答 Node.js 在打包管理器方面应该有哪些技术优先考虑的问题：

我不认为关于 Corepack 的问题已经成熟到 TSC 可以再次讨论。在那个线程中，有多人主张开设新的线程，试图就各种开放性问题达成共识。我建议针对 https://github.com/nodejs/node/blob/main/doc/contributing/technical-priorities.md 发起 PR，试图确定我们打算达成的目标，然后再考虑如何最好地实现这些目标的问题。我当时的想法是，这些 PR 可能是组织我们需要进行的讨论的一种方式，或者人们可以开设新的议题，比当前的议题更有针对性。无论如何，仍有许多开放性问题，我认为目前离 TSC 做出任何决定还有很大的距离。

与此同时，在 GitHub 上的讨论仍在继续，原始问题已经有 100 条来自关心结果的人的评论。

Borins 评论道：“我百分之百支持我们所能做的一切，以使开发者使用更加方便，减少首次使用的成本，改善使用体验，实现公平竞争。我并不支持强行让不想使用 Corepack 的团队采用它。”他代表 npm 重申了他的立场：

让我们以他们想要的方式发布 pnpm + yarn
如果那是做法的话，让我们取消对 Corepack 的标记
请不要强制 npm 使用 Corepack
如果你想深入研究解除默认绑定的 npm，请将讨论拆分开

最终， Node.js 技术指导委员会将在进一步的探索和讨论后做出决定。如果 Corepack 的使用证明如一些人怀疑的那样少，委员会是否有胆量默认启用它，并反对团队的意愿解绑 npm？这似乎不太可能，但仍是讨论的话题。

Node.js 合作者 Antoine du Hamel 评论道：“我不认为像 npm 那样将 Yarn 和 PNPM 转入 Node.js 是一个现实的选择（更多的安全问题，更大的捆绑包大小，而且可能与我们的 LTS 策略不太适应）。”

“我也不认为因为生态系统的影响，讨论解绑 npm 有什么意义。如果发布团队希望这样做（我认为他们是最有可能受到这个决定影响的人），我们可以讨论它，但走这条路似乎并不是非常有成效。（这就像 Node.js 和 npm 互相虚张声势，直到有一个项目屈服，或者每个人都失败）。"

为什么 Node.js 附带了包管理器

npm 的发明者和创始人 Isaac Schlueter 加入了 GitHub 上的讨论，提供了一些关于为什么 Node.js 自带包管理器的历史背景：

Ryan 和我看到用户在试图启动一个 node 项目时经常遇到困难，如果没有包管理器，他们就无法做太多事情，所以我们开始将 npm 和 node 一起发布。当时没有其他替代方案，这是由核心 node 团队的一员支持的一个方案，所以这是显而易见的选择。这在公开场合进行讨论，并不具有争议性；人们需要它，所以我们给了他们，就是这样。

他不认为为包管理器提供公平的竞争环境应该是 Node 的关注点，并鼓励社区检查 Corepack 是否是解决 Node 问题的最佳解决方案。

Schlueter 说：“不同的开源软件项目获得不同程度的曝光和分发，那又怎样？”“这非常像是非 Node 的问题。Node 应关心 Node 用户的使用体验和成功使用 Node，而不是任何给定的包管理器是否在‘市场’中占有‘公平’的份额。Node 应该包括一个替代的 JS 引擎或 TLS 实现，因为它‘不公平地’偏向 V8 和 OpenSSL 吗？‘公平性’对于像这样的问题是一个荒谬的标准。”

`Node.js` 需要明确地正式化其与包管理器的关系

对现状进行任何重大改变都需要有充足的理由，因为这可能会永久性地改变对 Node.js 生态系统和开发工作流程的长期影响，或许这并不利于创新和社区的积极参与。在项目的这个成熟阶段，是时候让 Node.js 明确地正式化其与包管理器的关系，这种关系应建立在其技术优先级的基础上。

Wes Todd 评论道，“除此之外，在这个讨论中，一个关键的问题一直被回避：Node.js 与构建和运行项目所需的各种额外工具之间应该如何正式确定关系？”“当我们开始讨论哪些标准可以让工具被包含在 Corepack 中，或者这个决定将如何检验和决定，我们没有得到明确的回答。”

这些问题在我们改变 JavaScript 包管理器的未来之前必须要有答案。随着 Node 社区继续围绕这些热点话题进行激烈争论，Todd 鼓励参与讨论的人要认识到 npm 对生态系统的贡献。

他说：“我明白，npm 在这种情况下有争议的地方，像是在它成为一个盈利实体之前就已经捆绑在一起。并且我理解我们所有人发布和从中安装的那个注册中心是那个交易的一部分，这在根本上是有问题的。

“但这并不能改变我们今天都在这里，拥有世界上规模最大的软件平台和用户群体，要归功于那些人的努力工作。即使在这条途径中遇到了难题，那些在 npm 上工作的人也都给这个生态系统带来了巨大贡献，甚至比我们大多数人如果亲自去做可能做得还要好。现在我们需要摆脱过去，开始讨论什么对 Node.js、它的维护人员、它的用户、以及更大范围的 JS 生态系统来说是最好的。”