[譯] 下一代包管理工具

摘要： 原文地址：Next Generation Package Management 原文作者：The npm Blog 譯文出自：掘金翻譯計劃 本文永久連結：github.com/xitu/g...

• 原文地址：ofollow,noindex">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 、前端 、後端 、區塊鏈 、產品 、設計 、人工智慧 等領域，想要檢視更多優質譯文請持續關注掘金翻譯計劃 、官方微博、知乎專欄 。