本文最初发布于 RedMonk。
最近，JavaScript 软件包管理领域发生了重大变化。虽然 npm 仍是 Node.js 运行时环境中使用的 JavaScript 软件包注册中心和管理器，但值得讨论的是，对于 JavaScript 代码交付这个更大的问题，这些变化有什么影响。具体来说，我想到了最近出现的 Deno 的 JavaScript 注册中心 JSR 和 vlt 的无服务器注册中心 vsr 。Deno 将 JSR 称为 “现代 JavaScript 的开源软件包注册中心”。它是由 Node.js JavaScript 运行时的创建者、Deno 联合创始人兼首席执行官 Ryan Dahl 开发的，在 JavaScript 社区中有着良好的发展势头。同时，自 2024 年 11 月在爱尔兰 NodeConf EU 大会上首次亮相以来，vsr 也引起了一些讨论。vlt 公司将 vsr 定位为 “一个简化的、隐私优先的私人开发和无缝分发环境”。由 Ruy Adorno、Darcy Clarke 和 Isaac Schlueter（npm 的创建者）共同创建的 vsr 也希望在这一领域有所作为。在 Node 和 npm 领域，Deno 和 vlt 都有着深厚的基因，它们都在通过软件包管理的方式进入软件包注册领域。我们来讨论下原因。
那么，什么是软件包管理器呢？软件包是归档文件，包括计算机程序及其部署所需的元数据。软件包管理器可以查找、安装、维护和卸载软件包。它们还管理软件依赖和版本信息，以避免兼容性问题以及缺少需要的东西。计算机操作系统需要 Linux 的 Yellowdog Updater Modified （YUM）、 dpkg（Debian Linux）、pacman（Arch Linux）、WinGet（Windows） 和 Homebrew（macOS）等管理器，而软件应用程序开发人员则需要管理器来处理构建应用程序所需的软件包。
RedMonk 一直在 关注软件包管理，但到 2025 年才发现，构建现代应用程序需要拉取和管理大量的依赖关系。例如，对于一个 React Native 项目，要在 CLI 中运行 npm install 命令，就会在 package.json 文件中添加近 1500 个依赖项。而且，这些依赖项往往还有自己的依赖项。这种沉重感并非 JavaScript 和 TypeScript 应用程序所独有，但一直是 SPA 大战 中的一个症结。JS 偏重于功能开发。姑且不论所有这些依赖关系是否必要，即使是最精简的应用程序也有非常多的软件包，所以第三方管理器是必不可少的。npm（JavaScript）、CPAN（Perl）、PEAR（PHP）和 PyPI（Python）等管理器都承诺简化依赖关系管理。这就要讨论下软件包注册中心这个错综复杂的话题了。
由于软件包管理器负责拉取外部软件源，因此必须与 GitHub、GitLab 和 BitBucket 等存储代码的软件源紧密集成。它们也依赖软件包注册中心来发布和共享这些软件包。GitHub 和 GitLab 将软件包托管作为一项服务提供，也就不奇怪了。毕竟，软件包只是以特定方式发布和使用的代码。
在 JavaScript (JS) 生态系统中，软件包管理器是 npm Public Registry API/ 基础设施的客户端，并受其限制。哇哦，凯特，你不是说 vsr 和 JSR 将取代 npm 吗？不是的。虽然所有注册中心都可以为发布和共享代码提供便利，但由于依赖性、生态系统锁定（CI/CD 管道、工作流）、与 Node.js 运行时的集成以及框架相互问题（React、Angular）等复杂的技术原因，目前几乎没有能用来替代 npm 的 JS 注册中心。也就是说， Bun 运行时、pnpm（Performant Node 包管理器）和 Yarn（Node JS 包管理器）都使用 npm 注册中心。本质上，如今的 JSR 和 vsr 都是 npm 兼容层。按照 JSR 网站 的说法，“JSR 并不是 npm 注册中心的替代品，而是 npm 的超集“。虽然在 推广 vsr 时， vlt 团队将其说成是 “现有软件包管理器的直接替代品”（说的大概是 npm），但与 JSR 一样，vsr 并没有取代 npm 注册中心，而是通过 “依赖关系查询选择器语法、导出格式（包括 Mermaid）和 GUI 体验 ”等附加功能提供隐私保护和更好的开发体验，帮助降低理解依赖关系图的门槛。
我勒个去！新 JavaScript 软件包管理器 Vlt 刚刚宣布， Isaac Schlueter 加入团队。Isaac 是 npm 的创建者。
现在，Node 的创始人在开发 JSR，而 npm 的创始人在开发 Vlt。激动人心的时刻 https://t.co/W6h1qctdr6
—— Wes Bos (@wesbos) 2024 年 3 月 20 日
关注 JS 软件包管理变革的原因有很多。首先，颠覆 npm 似乎可以赚钱。风险投资公司认识到了这一机遇，并为 Deno（来自 Shasta Ventures、Insight Partners 和红杉资本等的 A 轮投资）和 vlt（来自 Accel 和 Feross Aboukhadijeh 的 Pre Seed）提供了支持。除 JSR 外，Deno 还有其他多种产品，包括运行时、Web 框架和托管服务，而 vlt 则将全面推出功能丰富的私有注册中心。软件包注册中心（特别是 JS 社区的 npm）的价值主张一直是开发体验。没有人愿意回到编写 shell 脚本的痛苦中，更不用说 pip) 时代或管理 Ruby gem 了。事实上，Schlueter 一直非常希望，npm 能像其他语言的软件包管理工具（如 PHP 的 PEAR 和 Perl 的 CPAN）一样提供更好的体验。
在软件包注册中心领域，开发体验就是一切。因此，这些为服务于 TypeScript 和 JavaScript 社区而新创建的兼容 npm 的注册中心能否取得成功，似乎取决于 npm 是否充分满足了这一需求。来自 npm（Schlueter）和 Node（Dahl）创建者的新一批软件包注册中心可能是许多复杂信号的结果，如：1）市场规模（JS 的蛋糕很大）；2）市场控制（目前大多数 Node、JS、TS 和其他软件包都集中在一个地方）；3）开发者对卓越体验的需求。不过，从创建者那里，我听到最多的是最后一条。请看 Dahl 对目前“库和模块分发”的阐释：
我们认为 NPM 并不理想。因此，我们构建了 JSR，让 TypeScript 和 JavaScript 软件包的发布真正变得简单、友好。
显然，关于 JS 软件包注册中心这个话题，有很多可以说的。我们暂且退一步讲，谈谈初创公司为何热衷于这一领域，以及这对 npm 的未来有何启示。
我的意思是...... 如果我有什么要说的 —— 或者 —— @github + @thomas 可以提出让我们的团队收回 npm，并对 JS 生态系统进行必要的改进。DM 开启。
—— Darcy Clarke (@darcy) 2024 年 11 月 24 日
Npm 最初发布于 2010 年，在被微软收购两年之后于 2020 年被 GitHub 收购。说到 JS 包管理，npm 是无可争议的市场领导者。根据 Software House 2024 年前端现状报告，npm 是使用最广泛的软件包管理器（获得 56.6% 的投票），其次是 YARN（21.5%）和 pnpm（19.9%），但说到作为基础设施的注册中心，它是所有 JS 软件包构建的基础——不仅仅是 Node，还有 React 库、webpack 和 Typescript。
虽然在收购 GitHub 时，JS 社区中有一些人担心，这又是微软的“拥抱、扩展和消灭”策略，但社区中也有许多开发者对此举表示欢迎，因为与其他一些开源软件项目不同，npm 需要大量的资源和社区支持。当我向 GitHub 产品管理高级总监 Chris Patterson 问及 GitHub 的 npm 路线图时，他向我传递了这样的信息：
因此，NPM 的主要路线图是保持其安全性和高可靠性。坦率地说，这也是我们相当长一段时间以来一直在做的工作。要知道，软件包的下载量非常之大（涉及软件包的搜索、获取和提供），以及试图上传的垃圾信息非常之多（因为这是一个很宽的攻击面），要确保像 NPM 这样的服务非常安全又高度可靠，所有这些方面都需要付出巨大的努力。
与我交谈过的每个人都强调，npm 是一个巨大的成本中心。因此，在一个成熟的代码库（GitHub）的支持下，由大型云提供商（微软）提供支持是最理想的选择。运行 npm 的成本主要有两个方面：技术成本和运营成本。技术方面是数据存储，考虑到注册中心的规模和需要支持的下载量，数据存储变得非常重要。移动数据的成本并不低，而作为一个关键的网络基础设施，npm 无法承受宕机。据推测，微软收购 npm 后，这笔费用的负担可能就不那么重了，因为他们可以将这些数据存入自己的数据中心。然而，运营才是 npm 成本真正膨胀的地方。除了维护人员的工程劳动和办公空间（收购前， npm 在奥克兰市中心有一个办公室），运行这个注册中心的最大一笔开支就是所需的大量律师费。命名争议、抢注、商标研究和调解都需要大量的费用。
本质上讲，npm 需要一个好的归宿和雄厚的资金，但在收购计划中， GitHub 的领导层也将开发体验当成了核心。在一篇解释为什么收购 npm 的博文中，他们概述了发展的三大支柱：
投资注册中心基础设施和平台。JavaScript 生态系统规模庞大，发展迅速。它需要一个坚如磐石的注册中心。我们将进行必要的投资，确保 npm 快速、可靠且可扩展。
改善核心体验。我们将努力改善开发人员和维护人员的日常体验，并支持在 npm v7 CLI 上已经开始的出色工作。该 CLI 将保持免费和开源。有一些比较大的功能，让我们感到非常兴奋，包括工作空间以及在发布和多因素身份验证体验方面的改进。
与社区互动。我们将积极与 JavaScript 社区互动，了解社区的想法，帮助我们定义 npm 的未来。
遗憾的是，JS 社区越来越觉得， GitHub 已经放弃了这些支柱。事实上，在写这篇文章之前，我采访过的几位朋友都认为，npm 正在 KTLO（Keep the Lights On，维持基本运作）模式下运行，项目也因此受到了影响。我喜欢 Theo Browne 的说法：
[ GitHub / 微软] 为维护和发展 npm 生态系统付出了巨大的努力，即使我们所期待的体验和特性质量与多年前的旧版本相比并无多大改进。老实说，我已经不记得上一次 npm 注册中心发布有意义的新特性是什么时候的事了，我一直在密切关注这些东西。
在 npm 项目的众多因素中，安全可能最需要不断提供大量资源和积极支持的方面了。在我经常访问的在线开发者社区中，任何有关 npm 的新闻往往都是关注 Bug 和漏洞利用。Darcy Clarke 曾大肆宣扬，“npm 生态系统的核心存在着巨大的漏洞”。他批评的是， npm 软件包的清单文件是独立于其压缩包发布的，可能在本地编写，并不总是在 git 存储库中。与此同时，Reddit 和 Hacker News 上的开发者论坛上充斥着大量关于恶意和垃圾 npm 软件包的报道。除了 lottie-player 库漏洞之外，Exaforce 联合创始人兼工程主管 Jakub Pavlík解释说明了“NPM 生态系统安全的脆弱性，Phylum Research 的文章 “The Great npm Garbage Patch”讨论了 “与 Tea 协议相关的 npm 垃圾软件包激增的问题”。其中，Tea 协议是一个去中心化的方案，承诺用加密货币补偿软件开发者的开源贡献。此外，Alex Anderson 的文章 “Squatting npm for Remote Code Execution”也指出了一个潜在的漏洞：
作为概念验证，我注册了各种软件包，它们的名字与流行软件包中的 bin 脚本相匹配，可以列出自己的 bin 命令。这些 bin 命令是一种良性封装，会尝试运行用户预期的脚本。
恶意行为者可以将这些良性脚本替换成他们想要的任何内容，如数据渗入、修改、破坏；系统关闭等。
Node 社区尤其关注 npm 的状况。OpenJS 基金会执行总监 Robin Bender Ginn 说：
JavaScript 开发者社区告诉我们，他们发现 npm/GitHub 在安全性和性能方面存在着实际或可感知的差距。因此，随着新的软件包注册中心的不断涌现，JavaScript 生态系统面临着支离破碎的风险。由于维护注册中心的巨大负担、潜在的互操作性挑战和不断变化的安全合规性要求，这种结果并不理想。
所有这一切都为竞争创造了成熟的条件，而 Deno 和 vlt 正在应对这些竞争。但是，在软件包管理领域，并非只有它们填补了 npm 留下的功能空白。那么 JS 开发人员需要哪些特性呢？感兴趣的话，你可以在专门讨论 npm 的 GitHub 社区论坛（以前位于此处）上浏览特性请求和错误通知。2021 年有一个热门请求是深色模式。Myles Borins 对此做出了回答：“目前，在 npmjs.com 上，我们无法优先考虑深色模式“。
更严重的是，一些开发人员对官方网站 npmjs.com 上缺少文档表示失望。安全平台 Socket 可以说提供了比 npm 注册中心更好的软件包文档（见下方与 lodash 软件包的比较）。此外，作为 npm 的内容交付网络，UNPKG 允许用户以 npm 目前无法做到的方式提取和引用每个软件包压缩文件中的文件。通过深入了解软件包的内容，UNPKG 可以提供真正的代码分析。
