作者 | kate holterhoff
譯者 | 平川
策劃 | Tina
本文最初發佈於 RedMonk。
最近，JavaScript 軟體包管理領域發生了重大變化。雖然 npm 仍是 Node.js 執行時環境中使用的 JavaScript 軟體包註冊中心和管理器，但值得討論的是，對於 JavaScript 程式碼交付這個更大的問題，這些變化有什麼影響。具體來說，我想到了最近出現的 Deno 的 JavaScript 註冊中心 JSR 和 vlt 的無伺服器註冊中心 vsr 。Deno 將 JSR 稱為 “現代 JavaScript 的開源軟體包註冊中心”。它是由 Node.js JavaScript 執行時的建立者、Deno 聯合創始人兼執行長 Ryan Dahl 開發的，在 JavaScript 社群中有著良好的發展勢頭。同時，自 2024 年 11 月在愛爾蘭 NodeConf EU 大會上首次亮相以來，vsr 也引起了一些討論。vlt 公司將 vsr 定位為 “一個簡化的、隱私優先的私人開發和無縫分發環境”。由 Ruy Adorno、Darcy Clarke 和 Isaac Schlueter（npm 的建立者）共同建立的 vsr 也希望在這一領域有所作為。在 Node 和 npm 領域，Deno 和 vlt 都有著深厚的基因，它們都在透過軟體包管理的方式進入軟體包註冊領域。我們來討論下原因。
那麼，什麼是軟體包管理器呢？軟體包是歸檔檔案，包括計算機程式及其部署所需的元資料。軟體包管理器可以查詢、安裝、維護和解除安裝軟體包。它們還管理軟體依賴和版本資訊，以避免相容性問題以及缺少需要的東西。計算機作業系統需要 Linux 的 Yellowdog Updater Modified （YUM）、 dpkg（Debian Linux）、pacman（Arch Linux）、WinGet（Windows） 和 Homebrew（macOS）等管理器，而軟體應用程式開發人員則需要管理器來處理構建應用程式所需的軟體包。
RedMonk 一直在 關注軟體包管理，但到 2025 年才發現，構建現代應用程式需要拉取和管理大量的依賴關係。例如，對於一個 React Native 專案，要在 CLI 中執行 npm install 命令，就會在 package.json 檔案中新增近 1500 個依賴項。而且，這些依賴項往往還有自己的依賴項。這種沉重感並非 JavaScript 和 TypeScript 應用程式所獨有，但一直是 SPA 大戰 中的一個癥結。JS 偏重於功能開發。姑且不論所有這些依賴關係是否必要，即使是最精簡的應用程式也有非常多的軟體包，所以第三方管理器是必不可少的。npm（JavaScript）、CPAN（Perl）、PEAR（PHP）和 PyPI（Python）等管理器都承諾簡化依賴關係管理。這就要討論下軟體包註冊中心這個錯綜複雜的話題了。
由於軟體包管理器負責拉取外部軟體源，因此必須與 GitHub、GitLab 和 BitBucket 等儲存程式碼的軟體源緊密整合。它們也依賴軟體包註冊中心來發布和共享這些軟體包。GitHub 和 GitLab 將軟體包託管作為一項服務提供，也就不奇怪了。畢竟，軟體包只是以特定方式釋出和使用的程式碼。
在 JavaScript (JS) 生態系統中，軟體包管理器是 npm Public Registry API/ 基礎設施的客戶端，並受其限制。哇哦，凱特，你不是說 vsr 和 JSR 將取代 npm 嗎？不是的。雖然所有註冊中心都可以為釋出和共享程式碼提供便利，但由於依賴性、生態系統鎖定（CI/CD 管道、工作流）、與 Node.js 執行時的整合以及框架相互問題（React、Angular）等複雜的技術原因，目前幾乎沒有能用來替代 npm 的 JS 註冊中心。也就是說， Bun 執行時、pnpm（Performant Node 包管理器）和 Yarn（Node JS 包管理器）都使用 npm 註冊中心。本質上，如今的 JSR 和 vsr 都是 npm 相容層。按照 JSR 網站 的說法，“JSR 並不是 npm 註冊中心的替代品，而是 npm 的超集“。雖然在 推廣 vsr 時， vlt 團隊將其說成是 “現有軟體包管理器的直接替代品”（說的大概是 npm），但與 JSR 一樣，vsr 並沒有取代 npm 註冊中心，而是透過 “依賴關係查詢選擇器語法、匯出格式（包括 Mermaid）和 GUI 體驗 ”等附加功能提供隱私保護和更好的開發體驗，幫助降低理解依賴關係圖的門檻。
我勒個去！新 JavaScript 軟體包管理器 Vlt 剛剛宣佈， Isaac Schlueter 加入團隊。Isaac 是 npm 的建立者。 現在，Node 的創始人在開發 JSR，而 npm 的創始人在開發 Vlt。激動人心的時刻 https://t.co/W6h1qctdr6 —— Wes Bos (@wesbos) 2024 年 3 月 20 日
關注 JS 軟體包管理變革的原因有很多。首先，顛覆 npm 似乎可以賺錢。風險投資公司認識到了這一機遇，併為 Deno（來自 Shasta Ventures、Insight Partners 和紅杉資本等的 A 輪投資）和 vlt（來自 Accel 和 Feross Aboukhadijeh 的 Pre Seed）提供了支援。除 JSR 外，Deno 還有其他多種產品，包括執行時、Web 框架和託管服務，而 vlt 則將全面推出功能豐富的私有註冊中心。軟體包註冊中心（特別是 JS 社群的 npm）的價值主張一直是開發體驗。沒有人願意回到編寫 shell 指令碼的痛苦中，更不用說 pip) 時代或管理 Ruby gem 了。事實上，Schlueter 一直非常希望，npm 能像其他語言的軟體包管理工具（如 PHP 的 PEAR 和 Perl 的 CPAN）一樣提供更好的體驗。
在軟體包註冊中心領域，開發體驗就是一切。因此，這些為服務於 TypeScript 和 JavaScript 社群而新建立的相容 npm 的註冊中心能否取得成功，似乎取決於 npm 是否充分滿足了這一需求。來自 npm（Schlueter）和 Node（Dahl）建立者的新一批軟體包註冊中心可能是許多複雜訊號的結果，如：1）市場規模（JS 的蛋糕很大）；2）市場控制（目前大多數 Node、JS、TS 和其他軟體包都集中在一個地方）；3）開發者對卓越體驗的需求。不過，從建立者那裡，我聽到最多的是最後一條。請看 Dahl 對目前“庫和模組分發”的闡釋：
我們認為 NPM 並不理想。因此，我們構建了 JSR，讓 TypeScript 和 JavaScript 軟體包的釋出真正變得簡單、友好。
顯然，關於 JS 軟體包註冊中心這個話題，有很多可以說的。我們暫且退一步講，談談初創公司為何熱衷於這一領域，以及這對 npm 的未來有何啟示。
我的意思是…… 如果我有什麼要說的 —— 或者 —— @github + @thomas 可以提出讓我們的團隊收回 npm，並對 JS 生態系統進行必要的改進。DM 開啟。 —— Darcy Clarke (@darcy) 2024 年 11 月 24 日
Npm 最初發佈於 2010 年，在被微軟收購兩年之後於 2020 年被 GitHub 收購。說到 JS 包管理，npm 是無可爭議的市場領導者。根據 Software House 2024 年前端現狀報告，npm 是使用最廣泛的軟體包管理器（獲得 56.6% 的投票），其次是 YARN（21.5%）和 pnpm（19.9%），但說到作為基礎設施的註冊中心，它是所有 JS 軟體包構建的基礎——不僅僅是 Node，還有 React 庫、webpack 和 Typescript。
雖然在收購 GitHub 時，JS 社群中有一些人擔心，這又是微軟的“擁抱、擴充套件和消滅”策略，但社群中也有許多開發者對此舉表示歡迎，因為與其他一些開源軟體專案不同，npm 需要大量的資源和社群支援。當我向 GitHub 產品管理高階總監 Chris Patterson 問及 GitHub 的 npm 路線圖時，他向我傳遞了這樣的資訊：
因此，NPM 的主要路線圖是保持其安全性和高可靠性。坦率地說，這也是我們相當長一段時間以來一直在做的工作。要知道，軟體包的下載量非常之大（涉及軟體包的搜尋、獲取和提供），以及試圖上傳的垃圾資訊非常之多（因為這是一個很寬的攻擊面），要確保像 NPM 這樣的服務非常安全又高度可靠，所有這些方面都需要付出巨大的努力。
與我交談過的每個人都強調，npm 是一個巨大的成本中心。因此，在一個成熟的程式碼庫（GitHub）的支援下，由大型雲提供商（微軟）提供支援是最理想的選擇。執行 npm 的成本主要有兩個方面：技術成本和運營成本。技術方面是資料儲存，考慮到註冊中心的規模和需要支援的下載量，資料儲存變得非常重要。移動資料的成本並不低，而作為一個關鍵的網路基礎設施，npm 無法承受宕機。據推測，微軟收購 npm 後，這筆費用的負擔可能就不那麼重了，因為他們可以將這些資料存入自己的資料中心。然而，運營才是 npm 成本真正膨脹的地方。除了維護人員的工程勞動和辦公空間（收購前， npm 在奧克蘭市中心有一個辦公室），執行這個註冊中心的最大一筆開支就是所需的大量律師費。命名爭議、搶注、商標研究和調解都需要大量的費用。
本質上講，npm 需要一個好的歸宿和雄厚的資金，但在收購計劃中， GitHub 的領導層也將開發體驗當成了核心。在一篇解釋為什麼收購 npm 的博文中，他們概述了發展的三大支柱：
投資註冊中心基礎設施和平臺。JavaScript 生態系統規模龐大，發展迅速。它需要一個堅如磐石的註冊中心。我們將進行必要的投資，確保 npm 快速、可靠且可擴充套件。 改善核心體驗。我們將努力改善開發人員和維護人員的日常體驗，並支援在 npm v7 CLI 上已經開始的出色工作。該 CLI 將保持免費和開源。有一些比較大的功能，讓我們感到非常興奮，包括工作空間以及在釋出和多因素身份驗證體驗方面的改進。 與社群互動。我們將積極與 JavaScript 社群互動，瞭解社群的想法，幫助我們定義 npm 的未來。
遺憾的是，JS 社群越來越覺得， GitHub 已經放棄了這些支柱。事實上，在寫這篇文章之前，我採訪過的幾位朋友都認為，npm 正在 KTLO（Keep the Lights On，維持基本運作）模式下執行，專案也因此受到了影響。我喜歡 Theo Browne 的說法：
[ GitHub / 微軟] 為維護和發展 npm 生態系統付出了巨大的努力，即使我們所期待的體驗和特性質量與多年前的舊版本相比並無多大改進。老實說，我已經不記得上一次 npm 註冊中心釋出有意義的新特性是什麼時候的事了，我一直在密切關注這些東西。
在 npm 專案的眾多因素中，安全可能最需要不斷提供大量資源和積極支援的方面了。在我經常訪問的線上開發者社群中，任何有關 npm 的新聞往往都是關注 Bug 和漏洞利用。Darcy Clarke 曾大肆宣揚，“npm 生態系統的核心存在著巨大的漏洞”。他批評的是， npm 軟體包的清單檔案是獨立於其壓縮包釋出的，可能在本地編寫，並不總是在 git 儲存庫中。與此同時，Reddit 和 Hacker News 上的開發者論壇上充斥著大量關於惡意和垃圾 npm 軟體包的報道。除了 lottie-player 庫漏洞之外，Exaforce 聯合創始人兼工程主管 Jakub Pavlík解釋說明了“NPM 生態系統安全的脆弱性，Phylum Research 的文章 “The Great npm Garbage Patch”討論了 “與 Tea 協議相關的 npm 垃圾軟體包激增的問題”。其中，Tea 協議是一個去中心化的方案，承諾用加密貨幣補償軟體開發者的開源貢獻。此外，Alex Anderson 的文章 “Squatting npm for Remote Code Execution”也指出了一個潛在的漏洞：
作為概念驗證，我註冊了各種軟體包，它們的名字與流行軟體包中的 bin 指令碼相匹配，可以列出自己的 bin 命令。這些 bin 命令是一種良性封裝，會嘗試執行使用者預期的指令碼。 惡意行為者可以將這些良性指令碼替換成他們想要的任何內容，如資料滲入、修改、破壞；系統關閉等。
Node 社群尤其關注 npm 的狀況。OpenJS 基金會執行總監 Robin Bender Ginn 說：
JavaScript 開發者社群告訴我們，他們發現 npm/GitHub 在安全性和效能方面存在著實際或可感知的差距。因此，隨著新的軟體包註冊中心的不斷湧現，JavaScript 生態系統面臨著支離破碎的風險。由於維護註冊中心的巨大負擔、潛在的互操作性挑戰和不斷變化的安全合規性要求，這種結果並不理想。
所有這一切都為競爭創造了成熟的條件，而 Deno 和 vlt 正在應對這些競爭。但是，在軟體包管理領域，並非只有它們填補了 npm 留下的功能空白。那麼 JS 開發人員需要哪些特性呢？感興趣的話，你可以在專門討論 npm 的 GitHub 社群論壇（以前位於此處）上瀏覽特性請求和錯誤通知。2021 年有一個熱門請求是深色模式。Myles Borins 對此做出了回答：“目前，在 npmjs.com 上，我們無法優先考慮深色模式“。
更嚴重的是，一些開發人員對官方網站 npmjs.com 上缺少文件表示失望。安全平臺 Socket 可以說提供了比 npm 註冊中心更好的軟體包文件（見下方與 lodash 軟體包的比較）。此外，作為 npm 的內容交付網路，UNPKG 允許使用者以 npm 目前無法做到的方式提取和引用每個軟體包壓縮檔案中的檔案。透過深入瞭解軟體包的內容，UNPKG 可以提供真正的程式碼分析。
npm 和那些初創公司的故事提出了一個重要的問題，即這裡的商業模式是什麼？npm 是一個資金下水槽，不僅在技術上，更重要的是在讓人難受的持續運營成本上，涉及法律及其他方面。這也是微軟 /GitHub 最初接收 npm 所有權的前提，即無論誰想擁有它，都必須具有雄厚的資金。在我看來，有兩個比較大的問題：首先，Deno 和 vlt 都獲得了資金，但想必都說不上是腰纏萬貫。與 GitHub 相比，我們怎麼能期望它們可以把 npm 或其後續版本管理得更好？其次，將 npm 從成本中心轉變為利潤中心的財務模型是什麼？如果這些公司將自己定位為提供私有註冊中心，那麼本質上，它們只是在複製 npm 的商業模式，即對託管私有軟體包收費。如果它們還能提供更好的開發體驗，這可能會有不錯的吸引力，但市場是否認同這種做法，還有待觀察。
在結束關於 JS 軟體包管理器、npm 和軟體包註冊中心的討論之前，我想再說一下，我之所以關注這個領域，是因為它真的很重要。Web 上的很多內容都依賴於 npm 和 Node，而在開發中，這一部分因為看著不起眼而經常被忽視、冷落。軟體包管理器和註冊中心是開發人員及網際網路非常依賴的重要基礎設施。我很高興人們在這個領域不斷地發起挑戰，並期待看到他們能做出什麼樣的改進和最佳化。
原文連結：
https://redmonk.com/kholterhoff/2025/01/30/is-npm-enough/
宣告：本文為 InfoQ 翻譯，未經許可禁止轉載。
今日好文推薦