[譯] 下一代包管理工具

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