JavaScript 注冊表希望通過支持類型聲明文件等功能，為 JavaScript（以及 TypeScript）構建一個更好的包存儲庫。

譯自Behind the Scenes at the JavaScript Registry，作者 David Cassel。

自 3 月份公開測試版發布以來，JavaScript 注冊中心(JSR) 一直在播客、博客文章和網絡評論中為其好奇的開發者社區分享技巧、見解和普遍的善意。

“在 JSR 上發布的包作者很喜歡這種體驗，”Deno的產品營銷經理Andy Jiang在接受 The New Stack 的電子郵件采訪時表示。“JSR 在幕后處理了很多事情，因此作者可以發布 TypeScript 源代碼，而無需進行轉譯或構建步驟。”

這個開源網站是雄心勃勃計劃的一部分，旨在為JavaScript（以及TypeScript）構建一個更好的包存儲庫，支持類型聲明文件等功能，并提供一種簡單的方法來為包提供加密簽名。是的，雖然它專注于 JavaScript（和 TypeScript），但 JSR 僅支持 ES 模塊。在與 Stack Overflow 的春季采訪中，Ryan Dahl指出ECMAScript“現在已嵌入到所有 Web 瀏覽器中，是模塊的真正方式。”或者，正如存儲庫的常見問題解答所解釋的那樣，“ECMAScript 模塊已成為標準。

現代注冊中心

“現代注冊中心應該以 TypeScript 為設計理念。”

但現代 JavaScript 仍然受歡迎。“雖然我們確實希望從一開始就為 TypeScript 設計，但你絕對可以愉快地在 JSR 上編寫和發布純 JavaScript 代碼，”Deno 的開發者關系主管Kevin Whinnery在 3 月份在 Hacker News 上發布。（Whinnery 當時補充說，“我們可能需要更好地解釋和展示這一點”，而 JSR 的主頁現在自豪地宣布它是一個“用于現代 JavaScript 和 TypeScript”的包注冊中心。）

這一切都是持續推廣工作的一部分，旨在讓開發者熟悉有關新注冊中心的許多細節——并希望鼓勵他們嘗試一下

默認安全

在 Deno 的博客上，一篇4 月份的文章題為“我們如何構建 JSR”，解釋了該網站的一些內部細節，包括它“默認安全，支持來自 GitHub Actions 的無令牌發布以及使用 Sigstore 的包來源”。

一篇早期的3 月份博客文章包含將 GitHub 存儲庫鏈接到 JSR 的說明。“以這種方式發布還可以讓你的用戶放心，他們項目中包含的工件確實是從 CI 上傳的，并且有一個可供查看的來源透明度日志。”

正如 Dahl在 Stack Overflow 的播客上在 3 月份所說，“歸根結底，你將使用許多依賴項來構建你的微服務，然后將其作為 Docker 容器在某個 Kubernetes 基礎設施中運行。而且能夠說這個 Docker 容器中運行的所有軟件都有證明，可以追溯到某個經過驗證的用戶，并且這里沒有運行的代碼是我們不知道來源的，這將非常棒。我們正在構建這個基礎設施。”

4 月份的博客文章解釋了他們不僅必須構建一種強大的方式來托管包，而且還必須接受和分析新的包以查找無效的依賴項或語法錯誤（并計算一個分數以顯示包——并生成文檔）。

云端

但這篇博客文章還包含了一些關于他們如何構建基礎設施的有趣細節。大多數數據存儲在 Postgres 集群中，通過 HTTP REST API 使用 JSON 訪問。

API 服務器是用Rust編寫的，它與數據庫并排位于Google Cloud Run上，在那里它還“執行身份驗證和授權策略”，與 GitHub API 和 Sigstore 交談。在 Stack Overflow 的播客中，Ryan Dahl 強調 JSR “旨在能夠在商品云軟件上非常便宜地運行”。正如FAQ所說，“目前 JSR 的托管費用由 Deno 公司支付。未來，JSR 可能通過其他方式獲得資金，例如贊助、捐贈或基金會。”

“我們預計 Deno 公司能夠在可預見的未來繼續支付 JSR 的托管費用——JSR 的設計非常便宜。”

正如 Dahl 在播客中所說，“我們正在努力為 JavaScript 的未來建立一個機構。”

“[T]here is no magic，”博客文章承認。“我們使用非常無聊、非常容易理解且非常可靠的云基礎設施。”一個 Google Cloud L7 負載均衡器會將請求適當地路由到前端、API 服務器或托管源代碼和 npm tarball 的 Google Cloud CDN 后端。“那么我們如何使模塊服務變得可靠呢？我們將整個問題委托給 Google Cloud。與為 google.com 和 YouTube 提供服務的相同基礎設施用于在 JSR 上托管模塊……”

“只有當 Google 本身宕機時，JSR 才會宕機。但到那時——可能互聯網的一半都宕機了，所以你甚至不會注意到。”

那篇 4 月份的博客文章還詳細介紹了他們 Web 前端的具體細節。（因為“如果你正在編寫一項供人類使用的服務，你會很快發現大多數人類實際上并不想使用 curl 手動調用 API。”）他們使用 Fresh（他們將其描述為“一個現代的‘服務器端渲染優先’ Web 框架）構建了它，通過“并行化”許多 API 調用以同時運行來仔細優化它以實現快速響應。

包是如何發布的

最終結果令人驚訝地高效。發布腳本將文件捆綁到一個 .tar.gz 文件中，觸發 API 服務器執行自己的驗證（例如檢查 tarball 是否小于 20 兆字節）。根據博客文章，后臺工作者在 99% 的這些 tarball 上不到 30 毫秒內開始運行，驗證是否存在“name”、“version”和“exports”字段。對于大多數包，所有導入模塊的存在也將在 10 毫秒內得到驗證（以及 TypeScript 或 JavaScript 代碼的有效性）。

然后使用自動生成的模塊圖使用 Rust 中的 TypeScript 語法分析來創建文檔。

在服務的公開測試版期間，一篇3 月份的博客文章向潛在用戶解釋說，“一旦你找到了合適的模塊，安裝和使用說明可以在每個頁面頂部的模塊自動生成的 API 參考文檔中找到。”

在某個時刻，該服務甚至為 JSR 的 npm 兼容層生成一個 tarball，創建“node_modules/ 解析理解的導入”（通過將 TypeScript 源代碼轉換為 .js 文件和 .d.ts 聲明文件），“以及一個 package.json”。

根據 Deno 開發者關系主管Kevin Whinnery在 3 月份在 Hacker News上發表的評論，未來可能會有更多功能。“我們也一直在探索如何圍繞同時將 JSR 模塊發布到 npm 創建良好的開發者體驗，以便發布者也可以控制他們在那里的命名空間。我們當然知道這是人們感興趣的使用模式。”

然后，當然，Postgres 數據庫會更新……

關于那個前端

一篇新的上周的博客文章回顧了這一切的起源。在這篇文章中，產品設計主管John Donmoyer指出，除了其他一切之外，JSR 是開源的。因此，除了注冊表中添加的“數萬個”包之外，“我們很高興看到社區擁抱 JSR，來自 Deno 之外的 35 多位貢獻者貢獻了 240 多個額外貢獻。”

5 月份，Deno 的標準庫問世，為其提供了“自動生成的文檔和 SemVer 重復數據消除”，根據另一篇博客文章，“同時增強了全球開發者的可訪問性和多功能性”。（雖然它在 deno.land/std 的原始位置“將無限期地可用。所有依賴 deno.land/std 的程序將繼續工作。不用擔心！”）

Deno 標準庫包含 44 個模塊，涵蓋數據解析/操作、使用 Web 協議以及通用輔助函數，可能包含你所需的一切。https://t.co/9inNA4dMXehttps://t.co/CZybUAhr9apic.twitter.com/BFCeQbrsU0 — JSR (@jsr_io) [2024 年 8 月 21 日]

Donmoyer 還講述了 JSRF 標識設計的幕后故事——從他們采用 Chris Williams 的非官方 JavaScript 標識的黃色色調開始。但隨后設計團隊“開始玩弄‘塊’的概念，以喚起一個由許多較小部分組成的系統”，最終形成了 JSR 的鏡像文字——也就是說，一個旋轉 180 度后仍然相同的標識。

博客文章中的圖片還展示了他們考慮過的其他幾個版本……“最終成為 JSR 官方標識的概念最初只是一個匆忙的草圖，”Deno 前端工程師Josh Collinsworth回憶道。“我當時嘗試了很多想法，從我在設計學校期間完成的項目中汲取靈感……”

好奇 JSR 標識和網站設計是如何融合在一起的嗎？???

這里有一窺我們的設計過程。https://t.co/NoIeaOUFRn

— JSR (@jsr_io) [2024 年 9 月 4 日]

但工程師開始將其用作占位符——最終，開始為其代言。“我最初不愿將其定為贏家，因為我仍然認為它只是一個快速的概念草圖。但我們越是用它，它直截了當的簡潔性就越讓人感覺恰如其分。”

有趣的是，一件事是如何導致另一件事的。下一步是將網站其余部分的調色板與標識相匹配。最終，經常訪問的訪客意識到，他們的光標可以從頁面背景中始終向上漂浮的小方塊中畫出線條（這要歸功于令人愉快的開源庫particles.js）。最終結果“是一種有趣的視覺效果，它將 JSR 品牌和盒子主題聯系在一起，并融入了有趣的小互動。”（它也具有很高的性能——加載不到 10 千字節，這將在頁面其余部分加載后延遲加載。）

超越 npm

早在 JSR 處于公開測試階段時，一篇3 月份的博客文章承認了 npm 的 250 萬個包“以及僅在過去 30 天內約 2500 億次下載”，并表示這樣的數字使其“可以說是世界上最成功的包注冊中心。如果沒有 JavaScript 社區共同構建的這個令人難以置信的生態系統，JavaScript 可能不會享有今天的這種地位。”

但隨后它繼續談論 JSR 的價值主張。“我們認為，現在是重新構想包注冊中心在 2024 年應該如何運作的時候了。”

圖片

因此，想法是創建一個 npm 的擴展——但具有更大的雄心。在4 月份的一篇博客文章中，Dahl 認為 JSR“不僅僅是生態系統中的另一個工具，而是我們如何看待 JavaScript 和 TypeScript 分發方式的根本轉變……”

“JavaScript 是許多程序員的通用語言，使其既通用又易于訪問。這種語言值得一個中心樞紐——一個城鎮廣場——讓開發人員可以在沒有過分復雜的情況下分享他們的工作。

“我們相信 JavaScript 將在未來幾年內繼續成為軟件開發的核心，而 JSR 的目標是支持這種持久的重要性。”