為什麼要使用 JSR？

Node.js 的巨大成功在很大程度上是由 npm 的成功推動的。npm 擁有 2 百萬（即將達到 3 百萬）個套件，可能是歷史上最成功的套件管理員和儲存庫。JavaScript 社群應該對這項成就感到自豪。

那麼，既然有了 npm，為什麼還要建置 JSR？那是因為當今世界與 npm 最初推出時已不同

• ECMAScript 模組已成為標準。網路平台現在採用 ESM 作為首選的模組格式，取代了 CommonJS。
• JavaScript 執行時間不僅只有 Node.js 和瀏覽器。隨著 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 模組的網路標準是 ESM。一個現代化的套件註冊處應團結在這個標準之下，並引領社群朝這個方向邁進。因此，JSR 專為 ESM 設計。

跨執行時間支援

JSR 的目的是實現 JavaScript 可運作的任何地方都能運作，並且為 JavaScript 和 TypeScript 代碼提供與執行階段無關的註冊表。如今，JSR 可與 Deno 和其他會填入 node_modules 的 npm 環境合作。這表示 Node.js、Bun、Cloudflare Workers，以及其他使用 package.json 管理依賴關係的專案也可以與 JSR 互通。

我們計畫持續擴展對 bundler 和其他執行階段的支持，並記錄相關的 API 和技術。

JSR 是 npm 的超集

npm 註冊表因為世界各地開發人員的貢獻而獲得令人難以置信的成功。我們希望 JSR 能在這些成功上持續發展，而不是另起爐灶。JSR 是 npm 的超集，就像 TypeScript 是 JavaScript 的超集。

JSR 被設計為 與基於 npm 的專案和套件互通。您可以在任何使用 node_modules 資料夾的執行階段環境中使用 JSR 套件。JSR 模組可以從 npm 匯入依賴關係。

傑出的開發者體驗

JSR 具有許多旨在幫助模組發布者提高生產力的功能，包括但不限於

• 輕鬆發布只需一個命令即可 - CLI 會逐步引導您完成其餘部分
• 自動從原始碼產生 API 說明文件
• 零配置 從 GitHub Actions 發布
• 自動包含 .d.ts 檔案以供 Node.js/npm 發布
• 自動化的 TypeScript 最佳實務指南，可讓您的程式碼盡可能快速載入。
• 更多功能

快速、安全且可靠

JSR 旨為安全、快速且靈活，亦可在資源受限的環境中良好運行。

• JSR 使用全球 CDN 服務套件，並採用區域快取和高並行運算來加速下載。
• JSR 套件上傳不可變更，因此您可以確信套件在您下載後或是在您不知曉的情況下絕不會變更或遺失。
• JSR 套件下載很高效，僅會下載您要匯入的精確檔案。
• JSR 使用基於 OIDC 的驗證從 CI 發布套件，並使用無令牌互動式驗證流程從本機發布。

JSR 仍持續進化中

您的意見回饋對於 JSR 的成功至關重要。如果您有任何想法或意見回饋，說明 JSR 如何才能更妥善處理您的使用案例，請在 Discord 的 #jsr 或 #jsr-feedback 中與我們聯繫。

準備親自試用 JSR 了嗎？ 立即開始。