为什么选择 JSR？ - 文档

Node.js 的巨大成功在很大程度上得益于 npm 的成功。拥有 200 万（即将达到 300 万）个包，npm 可能是历史上最成功的包管理器和注册表。JavaScript 社区应该为这一成就感到自豪。

那么，为什么在 npm 存在的情况下还要构建 JSR 呢？因为当今世界与 npm 最初推出时已经不同了

ECMAScript 模块已成为标准。Web 平台现已采用 ESM 作为首选的模块格式，取代了 CommonJS。
除了 Node.js 和浏览器之外，还有更多 JavaScript 运行时。随着 Deno、Bun、workerd 和其他新 JavaScript 环境的出现，以 Node.js 为中心的包注册表不再适用于整个 JS 生态系统。
TypeScript 已成为事实上的标准。TypeScript 作为 JavaScript 的超集和最新 ECMAScript 特征的测试平台，已成为非平凡 JavaScript 代码库的默认选择。现代注册表应以 TypeScript 为设计理念。

除了这些不断变化的需求之外，还有机会改进 npm 的开发人员体验、性能、可靠性和安全性。JSR 的创建是为了满足这些新需求并抓住这些机会。

以下是一些我们认为您应该考虑使用 JSR 的原因。

原生 TypeScript 支持

JSR 的设计理念是支持 TypeScript。TypeScript 源文件直接发布到 JSR。原生支持 TypeScript 的平台（如 Deno）可以直接使用这些文件。

对于其他缺乏原生 TypeScript 支持的环境（如 Node.js），JSR 将把您的源代码转换为 JavaScript，并使用 .d.ts 文件分发您的模块，以支持 Node.js 项目的 TypeScript 工具。模块作者无需进行任何额外的配置或构建步骤。

JSR 还将从 TypeScript 源代码生成包的参考文档，提供丰富的在线文档，您可以与代码一起维护。

仅限 ECMAScript 模块

JavaScript 模块的 Web 标准是 ESM。现代包注册表应围绕此标准进行整合，并将社区引导到这个方向。出于这个原因，JSR 的设计仅限于 ESM。

跨运行时支持

JSR 的目标是在 JavaScript 可运行的任何地方都能运行，并为 JavaScript 和 TypeScript 代码提供一个与运行时无关的注册表。目前，JSR 与 Deno 和其他填充 node_modules 的 npm 环境兼容。这意味着 Node.js、Bun、Cloudflare Workers 以及其他使用 package.json 管理依赖项的项目也可以与 JSR 互操作。

我们打算随着时间的推移扩展对捆绑器和其他运行时的支持，并记录实现此目的的 API 和技术。

JSR 是 npm 的超集

npm 注册表因全球开发者的贡献而取得了巨大成功。我们希望 JSR 在此基础上发展，而不是对其进行分支。JSR 是 npm 的超集，就像 TypeScript 是 JavaScript 的超集一样。

JSR 旨在与基于 npm 的项目和包互操作。您可以在使用 node_modules 文件夹的任何运行时环境中使用 JSR 包。JSR 模块可以从 npm 导入依赖项。

出色的开发者体验

JSR 拥有许多旨在帮助模块发布者提高生产力的功能，包括但不限于

轻松发布，只需一个命令 - CLI 将引导您完成其余步骤
从源代码自动生成 API 文档
零配置从 GitHub Actions 发布
自动包含用于 Node.js/npm 分发的 .d.ts 文件
自动提供有关 TypeScript 最佳实践的指导，这些实践将使您的代码加载速度尽可能快。
更多

快速、安全、可靠

JSR 旨在安全、快速、灵活，并且在资源受限的环境中也能良好运行。

JSR 使用全球 CDN 来提供包，并使用本地缓存和高并行性来加速下载。
JSR 包上传是不可变的，因此您可以确信包在下载后永远不会更改或消失。
JSR 包下载效率很高，只下载您导入的精确文件。
JSR 使用基于 OIDC 的身份验证来发布来自 CI 的包，并使用无令牌的交互式身份验证流程来发布来自本地机器的包。

JSR 仍在不断发展

您的反馈对 JSR 的成功至关重要。如果您有任何关于如何使 JSR 更适合您的用例的想法或反馈，请在 Discord 的 #jsr 或 #jsr-feedback 频道中告诉我们。