- 原文地址:Next Generation Package Management
- 原文作者:The npm Blog
- 譯文出自:掘金翻譯計劃
- 本文永久連結:github.com/xitu/gold-m…
- 譯者:diliburong
- 校對者:CoderMing tvChan
如果希望在後臺僅僅通過 Node 就能達到非常快的依賴安裝速度該怎麼辦?如果你希望依賴項中的每個檔案都可以保證與登錄檔中的檔案是完全一致該怎麼辦?如果在新專案上工作就像克隆和執行一樣簡單呢?如果你的構建工具並不合適怎麼辦?
下面將介紹 tink
,一個 install-less
安裝程式的概念驗證實現。
tink
作為 Node.js 本身的替代品,以你現有的 package-lock.json
檔案為工作基礎。在沒有 node_modules
目錄的專案上嘗試之後你會發現,即使從來沒有執行過安裝,依舊可以使用 require
關鍵詞來匯入任何依賴項。第一次執行也許需要花費幾秒鐘的時間來下載和提取包的壓縮檔案。但是之後的執行幾乎能夠瞬間完成,即使依舊會核查來確保 package-lock.json
中的所有內容都在系統上。
你會注意到的第一件事是這些模組實際上都沒有放入 node_modules
目錄下,唯一能找到的就是一個 .package-map.json
檔案。這個檔案中包含了已安裝的包模組中的所有檔案的雜湊值。你可以放心地獲取所請求的內容,因為它們在載入前已經被驗證過了。(如果驗證失敗,則檔案將從其原始源獲取,所有過程都是透明的)。
不過我們並不會良莠不分全盤否定之前的方案。你仍然可以將內容安裝入 node_modules
目錄,這些版本相對快取版本來說會被優先使用。這為依賴項的實時編輯(有時是必要的除錯技術)開啟了一條路徑,並支援改變軟體包分發的 postinstall 指令碼。
tink
是一個改變我們與 Node.js 專案以及 npm 登錄檔相關聯方式的機會。是否應該在模組中使用 requrie
或者 import
關鍵詞而不是在 package.json
來新增依賴?是否應該預設提供一些像相容 babel 的 ES Module、typescript 以及 jsx 這樣非常受歡迎的功能?這些是我們一直在問自己的問題,我們很樂意聽到您所期望的下一代體驗。請來 npm.community 告訴我們。
如果發現譯文存在錯誤或其他需要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群,文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域,想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。