其他註冊表

除了 JSR 之外，還有多個平台可以分享 JavaScript 函式庫。在本節中，我們將重點說明各種選項之間的差異。

npm

npm 是分享 JavaScript 函式庫的主要且廣為認可的平台。它最初在 2010 年代初期隨著 Node.js 開發。

JSR 的設計是補充 npm，而不是取代它。JSR 允許套件使用 npm: 規格來參照 npm 套件。

JSR 套件也可以用於尚未原生支援 JSR 的工具中，方法是使用 JSR 的 npm 相容性層。

我們建立 JSR 是為了解決 npm 生態系統中的特定問題

• 原生 TypeScript 支援：JSR 在發佈之前不需要 TypeScript 程式碼轉譯。它明確建立為支援 TypeScript 功能，例如「go-to-definition」，避免不必要地遇到宣告檔 (d.ts)。
• ESM 語法：JSR 推動現代 ECMAScript 模組 (ESM) 語法，勝過 CommonJS，啟用簡化的程式碼結構。
• 更好的限制：JSR 執行各種約束，增強 Unix 和 Windows 平台之間的可攜性，例如路徑長度限制和禁止某些檔案名稱。

deno.land/x

JSR 和 deno.land/x 共享相同的起源，但 JSR 被設計為相容於各種執行時間和打包器。

deno.land/x 做為存放庫來存放源程式碼，可透過 HTTPS 存取。JSR 的目的是為了解決 deno.land/x 的幾個問題

• 語意版本號執行：Deno.land/x 沒有執行語意版本號 (semver)，造成重複依存項的問題。因此，模組圖表中可能會出現同一個函式庫的許多版本。
• 可靠性：Deno.land/x 缺乏獨立連結，包括連結到潛在不可靠伺服器，這些伺服器可能在程式碼發佈之後就離線。這會影響長期信賴 deno.land/x 函式庫的可靠性。
• TypeScript 效能：雖然 Deno 和 deno.land/x 提供原生 TypeScript 支援，但從 deno.land/x 使用 HTTPS 模組時，會有效能問題。類型檢查器可能會持續分析程式碼，超出使用者的控制範圍，而影響效能。

esm.sh

Esm.sh 是透過 HTTPS 來服務 npm 套件的平台。在 Deno 提供原生 npm 支援之前，這是將 npm 依賴項包含在 Deno 程式中的首選方法。

與 esm.sh 相對，JSR 沒有直接服務 npm 套件。JSR 運作為獨立的登錄，允許 npm 依賴項，同時主要關注純 JSR 程式碼。

類似 esm.sh

• 僅限 ESM 模組：esm.sh 和 JSR 都特別提供 ESM 模組，而非 CommonJS。
• 直接存取檔案：和 esm.sh 一樣，JSR 透過 HTTPS 提供對個別套件檔案的直接存取。

unpkg.com

unpkg.com 與 esm.sh 相似，允許透過 HTTPS 存取 npm 模組中的個別檔案。但是，與 esm.sh 相比，它提供的功能較少。