Node.js技术指导委员会已确认，在持续讨论启用Corepack默认设置的情况下，将npm从Node.js发行版中移除不是项目的目标。

Node.js技术指导委员会（TSC）本周举行了会议，并在关于启用Corepack默认设置的更广泛讨论中做出了一些关键决定。与会成员确认已经达成共识，即没有打算移除npm。

围绕Corepack的讨论之前曾引发了这样一个问题：npm是否将通过Corepack提供，因为一些贡献者认为将npm从Node.js发行版中移除是整合Corepack的最终目标。

TSC成员Geoffrey Booth上周提交了一个PR，合并了这个共识。它指出移除npm不是项目的目标：

作为解决TSC成员在2024年1月24日会议上提出的请求的一部分，此PR旨在帮助澄清Corepack的目标。特别是，这澄清了这不是Node.js整体的目标，因此也不是包括Corepack在内，致力于从Node.js发行版中移除npm。

这也是对#50963 (comment)中所写的内容进行编码，该内容似乎达成了共识：

1. 我们巩固与npm客户端的“特殊关系”，明确说明它是因为它是npm注册表的参考实现，以及出于历史原因而被捆绑的。

该PR更新了Node.js的技术优先事项文档，添加了一个新的包管理部分：

能够轻松安装和管理依赖项和开发工具是用户体验的关键部分，因此Node.js必须作为其发行版的一部分提供包管理器。Node.js包含npm用于此目的。这是出于历史原因——当npm于2011年添加时，它是唯一的JavaScript包管理器——以及因为它是npm注册表的参考实现，这是大多数JavaScript软件的事实上的主要来源。根据我们不包括服务于相同目的的多个依赖项或工具的政策，Node.js项目不包括任何其他包管理器；尽管它可能包括其他软件来下载其他包管理器。

这个PR是在2024年1月24日TSC会议之后进行的，该会议旨在澄清Corepack在Node.js生态系统中的目标。它确认，无论在追求启用Corepack的过程中讨论了什么想法，从Node.js项目中移除npm都不是目标。

TSC成员代表着多样的观点和利益，这个PR并非没有一点抵触。

"TSC成员Yagiz Nizipli表示：“我反对。解除npm的捆绑应该是长期目标。”

最终，大多数成员赞成将解除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承担占位符中包含的任何安全问题。

“即使我们在某处有一些声明，以某种方式表示我们对Yarn软件中的任何漏洞不负责任，我认为很多用户可以合理地认为这并不能使我们免责：即使Yarn实际上并未捆绑在我们的发行版中，我们也应该为Yarn提供与npm相同的安全保证。” Booth在PR中说道。

Booth还认为，这将使得兼容性和更新策略变得更加复杂，因为可执行文件的主要更新必须与Node的时间表保持一致，从而降低了灵活性，可能会延迟更新。此外，锁定到特定版本或锁定到主要版本线内的最新版本的占位符，可能会导致用户体验较差，与现有的安装方法相比。

Booth认为，占位符可执行文件还起到了不必要的“政治”作用，并暗示了对该软件的推荐：

正如捆绑npm可以被认为暗示了对npm的推荐一样，发布占位符也意味着对那些其他工具的等效推荐。显然，对npm的竞争对手来说，这是可取的，但我认为这不是我们作为一个项目想要走的路：明确地说，我们是中立的，对任何工具都没有推荐，要比对每个提议创建占位符的工具进行辩论要容易得多。

Booth的PR建议项目划定界限，并声明Node.js将不创建占位符可执行文件（命令指向的软件未与Node.js捆绑在一起，而是在运行命令时下载）。

TSC计划在下周进行更多有关占位符可执行文件的讨论，作为Corepack决策的一部分。在本周的会议上，Booth鼓励参与者不要太过苛刻地纠缠于措辞，而是朝着Node.js是否允许占位符的决定前进，或者只允许它们用于包管理器。如果允许，Node.js是否必须对其负责？这将给项目带来什么成本？这个决定可以有多种方式进行。

Corepack的讨论正在进行中。做出关于占位符可执行文件的决定将使TSC能够更好地处理有关默认启用yarn和pnpm Corepack二进制文件和启用Corepack默认设置的替代方案的未解决PR。