[译] 下一代包管理工具

• 原文地址：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、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。