在过去几年中，出现了像 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 使用 软件工件供应链级别 创建高级的可验证来源证明，并将其存储在 Sigstore 中。这不仅保证了代码的真实性，而且在开发人员实施的内容中建立了信任和问责制。
JavaScript 是许多程序员的通用语言，使其既通用又易于访问。该语言应该有一个中心枢纽——一个城镇广场——开发人员可以在那里分享他们的工作，而无需过度的复杂性。我们相信 JavaScript 将在未来几年内继续成为软件开发的核心，而 JSR 旨在支持这种持久的相关性。虽然 JSR 不是一个包管理器，但它提供了一种管理和保护代码的新方法，旨在成为一个稳定、面向未来的平台，它将增强和保护 JavaScript 开发。通过这种方式，JSR 不仅仅代表生态系统中的另一种工具，而是我们思考 JavaScript 和 TypeScript 分发方式的根本转变。
🚨️ 了解更多关于 JSR 的信息 🚨️