在过去的几年中，像 yarn 和 pnpm 这样的新包管理器出现了，它们增强了包的下载方式。然而，作为 JavaScript 生态系统基石的 npm 包注册表几乎没有发展。它上次值得注意的更新是在几年前添加的“文件”标签。以其充满活力的演变而闻名的 JavaScript 语言，似乎矛盾地陷入了一个没有跟上步伐的分发模型中。

当我创建 Node 的时候，JavaScript 并没有标准的模块系统。因此，npm 注册表和 Node 默认使用 CommonJS (require)，这是一个有根本缺陷的系统，使其在浏览器中无法工作。所以，大约十年前的 2015 年，语言采用了 ES 模块 (import) 的语法。今天，大多数 JavaScript 是使用 ES 模块编写的，但是分发这些模块的途径仍然复杂，特别是当涉及到 TypeScript 时。这个生态系统中的明显缺口促使创建了 JSR，它不是作为另一个包管理器，而是作为一个变革性的注册表，旨在彻底改变 JavaScript 和 TypeScript 在服务器端运行时、浏览器和各种工具之间的共享方式。

JSR 通过简化长期以来困扰开发人员的复杂性，从根本上改进了代码分发过程。通过仅支持 ESM 和优先考虑 TypeScript，JSR 消除了令人沮丧的 package.json 配置和复杂的 tsconfig 编译器选项的杂耍。通过 一个包评分系统，JSR 激励代码分发的最佳实践——为包含每个导出符号的全面 JSDoc 文档的包授予更高的分数，类似于 Dart 社区在 pub.dev 中拥有的。正如在 Go 和 Rust 等其他现代编程生态系统中看到的那样，JSR 提供了开箱即用的自动文档生成。

JSR 是一个注册表，而不是 npm 注册表的另一个客户端。但这并不意味着你需要放弃 npm 的一切，或者硬切换到一个与 JavaScript 模块不兼容的生态系统。JSR 旨在补充 npm 注册表，而不是取代它。JSR 包被允许依赖 npm 包 - 例如，查看这个包。此外，JSR 包可以在现有的 npm 优先软件中使用，因为 JSR 本身充当一个 npm 注册表（可在 npm.jsr.io 访问），分发与 npm 兼容的 tarballs。这允许 JSR 包被任何使用 npm、yarn 或 pnpm 的软件包含，以及与 私有注册表 集成。JSR 分发的 npm tarballs 是最优的。

在 Deno，我们将安全性作为 JavaScript 开发中的首要关注点。虽然没有任何注册表可以全面监管所有发布的代码，但 JSR 提供了关于其发布者的透明度，并保护了发布过程。通过将 OIDC 令牌与 GitHub Actions 集成，JSR 使用 Supply Chain Levels for Software Artifacts 创建了先进的、可验证的来源证明，并将其存储在 Sigstore 中。这不仅确保了代码的真实性，而且建立了开发者正在实施的内容的信任和问责制。

JavaScript 是许多程序员的通用语言，使其既普遍又易于访问。这种语言值得拥有一个中心枢纽——一个城镇广场——开发者可以在这里分享他们的作品，而无需不必要的复杂性。我们相信 JavaScript 将在未来许多年继续是软件开发的核心，JSR 的目标是支持这种持久的相关性。虽然 JSR 不是一个包管理器，但它提供了一种新的管理方式和保护代码的方法，志在成为一个稳定、前瞻性平台，增强和保护 JavaScript 开发。以这种方式，JSR 代表的不仅仅是生态系统中的另一个工具，而是我们思考如何分发 JavaScript 和 TypeScript 的根本转变。