JavaScript 社区最近被一个新的包注册中心 JSR 点燃了热情，该项目来自开发 Deno 的团队。Deno 是一个基于 V8 JavaScript 引擎和 Rust 构建的 JavaScript、TypeScript 和 WebAssembly 的运行时。

Deno 团队一直致力于为 JavaScript 开发提出新的选择。在详细回顾了 Node 早期设计时的遗憾之后，Node.js 的创建者 Ryan Dahl 于 2018 年的 JSConf EU 会议上公布了 Deno 项目。这个项目的目的是提供一个更快、更安全的 JavaScript 运行时，Deno 团队还将 Node/npm 的兼容性作为 Deno 项目的核心组成部分。

为了推动 Deno 的发展，Deno Land Inc. 于 2021 年成立，资金由 Shasta Ventures 和 Mozilla Corporation 提供。一年后，Deno 在红杉资本领投的 A 轮融资中获得了 2100 万美元的额外资金。

JSR 是 Deno 为重新定义 JavaScript 包注册中心领域做法而做出的最新努力。与长期以来被 JavaScript 生态系统视为标准包注册中心的 npm 相比，JSR 有几个明显的技术差异。Deno 团队在 2023 年 SeattleJS 会议上非正式宣布了 JSR 项目，并在 2023 年更新的博文中附上了该项目的链接。

几周前，JSR 网站总结了 Deno 正在构建的内容：

  • 为什么要选择 JSR？ 真正的 TypeScript 优先环境：高效的类型检查，无需转换过程 —— 直接用 TypeScript 编写并部署代码。
  • 性能和可用性处于最前沿： 通过集成的工作空间和无缝的 NPM 集成，JSR 将可用性放在首位。
  • 安全且可访问的模块： JSR 中的所有模块都通过 HTTPS 公开，确保代码始终是安全的。
  • 开源，由社区驱动： JSR 由开发人员为开发人员构建，是根据 JavaScript 社区实际需求和贡献逐步形成的。

开发一个新的 JavaScript 注册表以解决 npm 的局限性

在 Deno 2.0 发布会上，Deno 的 DevRelKevin Whinnery解释了创建新的软件包注册表的动机：

我们面临着一个决定，我们决定是否需要朝着这个集中式软件包管理的方向前进。npm 是适合我们的东西吗？我们投入了大量工作来弄清楚情况是否如此，但出于某些原因...我们最终发现，npm 中包含了许多我们在 Deno 环境中不一定需要的东西。

因此，我们最终决定是时候为我们构建一个新的集中式软件包管理器了，它首先专为 Deno 而构建，此注册表的一些功能在于，我们确实希望对注册表中的内容采取编辑立场，因为我们希望阻止对特定名称的模块和软件包的抢占，并防止废弃的模块占用一个命名空间。我们希望在需要时保留采取该编辑立场的权利。我们希望确保发布到注册表的软件包使用语义化版本控制并且使用 Typescript。

Whinnery 说他们希望该注册表确保进行了许可配置，以便可以成功使用软件包。Deno 还以一种可以保留通过 HTTPS 导入获得的大量效率的方式构建该注册表。

他说：“我们非常热衷于这个方向，而且，我们并不是试图复制粘贴 node.js — 我们试图创造不同的开发者体验，我们认为这个注册表将成为我们试图创造的开发者体验的关键部分。”

2023 年 3 月，当 Deno 添加对 package.json 的支持 以增强对 Node 和 npm 的兼容性时，Dahl 重申了他的团队对使用 HTTP 导入作为 Deno 模块系统的支持。他还批评了 JavaScript 生态系统的既定规范，这些规范历来严重依赖集中式存储库进行模块分发。他对 Deno 的愿景是利用网络的分散化基本原则，追求一种更灵活、更安全的方法来管理依赖关系。

Dahl 说：“JavaScript 生态系统对 单个集中式模块注册表 的依赖与网络的分散化性质存在冲突。”“随着 ES 模块 的引入，现在有一个加载远程模块的标准，并且该标准看起来与 npm 通过 npm 的模块加载方式完全不同。Deno 通过 HTTP URL 实现加载 ES 模块 - 允许每个人只需运行文件服务器就可以在任何域上托管代码。"

第一印象：开发人员评价 JSR 的潜力

少数开发人员已获得了 JSR 的早期访问权限，而大多数人还在等待名单上。到目前为止，有关 JSR 的信息很少，但少数人已经发布了他们的初步印象。

“它解决了 deno.land/x 提出的许多问题，但以一种保留代码包管理的所有优势的方式，”Deno Land 的前工程主管 Kitson Kelly 在他的早期评论中表示。“除此之外，与 Javascript 生态系统其余部分互操作的能力确实是解决了许多现实问题。

“至少拥有一个使 TypeScript 与 Javascript 并驾齐驱的注册表是很重要的。这是我们在 Deno 领域多年来一直具备的优势，但到目前为止，Javascript 生态系统其他部分无法轻易获得。”

Kelly 赞扬了为 JSR 做出的几项架构决策，包括服务器支持、引入“zapped”代码验证，这在无需完整控制流分析的情况下提供了更快的 TypeScript 类型检查、利用 JSDoc 和 TypeScript 注解自动从源代码生成文档，以及 JSR 的故意限制 —— 只允许 JSR、npm 包或 Node.js 内置的依赖关系，以维护受控且安全的包生态系统。

Wasmer 创始人 Syrus Akbary 也获得了 JSR 的早期访问权限，并在 X/Twitter 中发表了他的想法。

“它将自己定位为 NPM 的替代品，同时独立于运行时，这非常好，”阿克巴里说。“但是，发布新包需要 deno。manifest 文件名为 deno.json，你需要使用 deno publish。

“我知道来自 Deno 的人在这里尽了最大的努力，但或许将发布/使用与 deno 分开会更有益。”

“到目前为止，我还没有看到任何与其他代品 (npmjs.com)产生数量级的差异特性，这让我有点儿不愿意接受它，”Akbary 说。“JSR.io 目前感觉像是 Deno 的包管理器版本，它允许通过清单而不是代码定义依赖关系。但是，我为什么要使用它而不是 npm？我知道它只兼容 ES 模块... 但这是一个很大的区别吗？

“总而言之，我希望事情会有所改善，我希望看到他们如何继续进行迭代。”

JSR 可能对 TypeScript 开发人员最具吸引力，因为其 TypeScript 优先的环境简化了发布包的过程。

“对于 Deno 和 TypeScript 编码人员，我认为 JSR 将成为未来发布包的地方，” 网络开发者 David Bushell 在他的评论中说。“特别是如果它们是跨运行时兼容的话。

“JSR 是否会取代 npm？不太可能，但就像 Deno 所做的那样，我希望 JSR 能够给 Node 和 npm 带去一团火，并促使它们更快地实现现代化。如果没有标志，Node 仍然没有一流的 ESM 支持。是否有像 Bun 那样对 Node 提供一流 TypeScript 支持的未来？类型会出现在 ECMAScript 标准中吗？现在我在做梦。

“无论如何，JSR 很棒。TypeScript 支持和 npm 兼容性是杀手级功能。对 NPM 的其他改进很小，但值得欢迎。”

JSR 致力于 npm/Node 兼容性消除生态系统碎片化担忧

目前，Deno 将其大部分针对 JSR 的计划严加保密，因为他们可能正在处理早期测试人员的反馈。有些人渴望在 JavaScript 生态系统中看到更多的竞争。

“对于这个新的 JavaScript 软件包注册表将带来的创新，我感到很兴奋”，彭博 JavaScript 工程师 Rob Palmer 说。

“拥有一个能感知源的注册表是一项胜利，而不仅仅是运送包含预编译构建输出的任意文件存档。”

这种乐观情绪也可以与 Reddit 回复进行对比：

“请不要。没有人要求它。”

“Deno 生下来就死了。停止尝试分裂生态系统。Node 运行得很好。”

最直言不讳的反对意见来自那些认为 Deno 和 JSR 是“对 Node/npm 生态系统的边缘改进，（如果被采用）对每个人来说都将是巨大的破坏性改变。”

其他人认为竞争是健康的，因为备选运行时、注册表和软件包管理器可以推动生态系统中的主要参与者朝着积极的变化发展。

“Deno 和 bun 都是不错的竞争对手”，Reddit 用户 AtrociousCat 评论道。“即使你从不打算从 Node 切换，这种竞争的存在也促使 Node 维护人员稍微关注一下性能。Bun 正在尝试新事物，即使它消亡了，也可能有一些好主意会进入 JS 生态系统。”

针对 JSR 将分裂生态系统的批评，Reddit 用户 NormQuestioner 的回应强调了人们对这个问题的不同看法：

非常奇怪的看法。Deno 解决了很多 Node 存在的问题，并允许开发人员以更易于维护的方式完成工作，从而极大地改善了 DX。

如果说有的话，当人们在他们不需要的时候坚持使用 Node.js，那就是正在分裂生态系统。

如果 JSR 流行起来，它就有可能创建一个新的生态系统，但 JavaScript 社区在没有看到足够吸引人的好处来保证转换的情况下会犹豫是否采用它。

“我最大的担忧是社区分裂”，网络开发人员Kent Dodds。“当 GitHub 宣布他们的软件包注册表（在收购 npm 之前）时，我也有类似的担忧，但似乎没有人使用它，所以这个担忧从未实现。

“如果这个得到大量使用，那么我担心我们将有两个流行的注册表，这将非常烦人。我确定他们已经解决了这个问题，但我希望听到他们计划如何解决它。npm 不会消失。”

针对在 X/Twitter 上关于社区分裂的担忧，Deno 的 DevRel 凯文·惠内里说，“JSR 被设计为 npm 的超集，而不是替代品。JSR 软件包可以在使用 (p)npm/yarn 和 node_modules 的 Node/Bun/* 项目中使用。你可以在 JSR 软件包中依赖 npm 软件包。”

虽然 Deno 团队正在积极努力帮助开发人员顺利地从 Node 过渡到 Deno，但他们认识到在整个生态系统中构建兼容性的重要性。这种兼容性对他们自己的成功至关重要。有些人可能会认为，没有这种兼容性，他们就没有成功的机会——如果他们想蓬勃发展，就必须允许开发人员利用 Deno 的优势，而不会牺牲 Node 生态系统的庞大资源网络。

“在像 Rust 这样更底层的语言中构建一个新的 node.js 版本不是 Deno 的目标，”惠内里说。“仅仅重写一个更好版本的 Node，它可以逐步地更快和更好，这不是一个非常有趣的理由来承担这样的项目。Deno 的真正目标是尝试从根本上简化面向云构建软件的方式。”

新的 JSR 注册表旨在解决开发人员在使用 npm 时遇到的与安全性、软件包分发和依赖管理相关的挑战和限制。JSR 的访问权限尚未向候补名单开放，但一旦开放，更广泛的早期评论将更好地展现 Deno 团队在说服社区采用 JSR 方面需要投入多少精力，这最终将决定 JSR 作为生态系统中的竞争性替代方案的可行性。