[译] 将项目迁移到 Yarn 而后又迁回 npm

• 原文地址：To Yarn and Back (to npm) Again
• 原文做者：Spencer Brown
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：DM.Zhong
• 校对者：Starriers，wyh888

去年，咱们决定将全部 JavaScript 项目从 npm 迁移到 Yarn。

之因此这样作，有如下两个主要缘由：

• yarn install 比 npm install 快 20 倍。npm install 在咱们的一些大型项目中每每须要消耗 20 分钟以上。
• Yarn 的依赖锁定比 npm 的更加可靠。

查看去年的一篇博客（连接在上方给出了）能够了解更多。

使用 Yarn 的 13 个月

Yarn 解决了咱们在使用 npm 时所遇到的一些烦人的问题，可是它自身也带来了许多的问题：

• Yarn 出现了很是很差的回归，这让咱们不太敢升级它。
• Yarn 常常会在你运行 add，remove 或者 update 的时候生成无效的 yarn.lock 文件。这就使得开发者须要作一些冗余的工做来 remove 和 add 这些有冲突的包，直到 Yarn 找出解决方案以使得 yarn check 可以经过，才能改善这一现象。
• 不少时候，由于 Yarn 进行了优化,因此当开发人员在拉取项目的最新变化后运行 yarn 时，他们的 yarn.lock 文件会变的很“脏”，。为了解决这个问题，须要开发人员推送与他们工做无关的更改。Yarn 须要在使用命令 yarn lock 更新时当即优化，而不是在下一次使用 yarn 命令时。
• yarn publish 不是很可靠（存在问题？）（tracked issues #1, tracked issue #2），这意味着咱们不得不使用 npm publish 来发布包。这使咱们很容易忘记在这种特殊场景下须要使用 npm，而且意外地使用 Yarn 发布包致使发布的包没法安装。

不幸的是，在咱们使用 Yarn 的 13 个月里，这些工做流很混乱的问题一个都没有被修复。

在经历了特别痛苦的几个星期（常常开 15 分钟的 Yarn 问题解决会议）后，咱们决定回归到 npm。

npm 6

在咱们使用 Yarn 的这段时间里，npm 作出了重大的改善，以期拥有 Yarn 的速度及其依赖锁定的可靠性 —— 这些问题曾使得咱们转向了 Yarn。就像 Yarn 里面的那些烦人的问题同样，咱们没法离开这些好处，所以咱们首先须要验证一下 npm 是否解决了原来的那些问题。

咱们决定尝试一下当前可以获取到的最新版本的 npm，npm@​6.0.0，由于咱们想要利用尽量多的速度改善和 bug 修复。据传 npm​@6.0.0 是一个相对较小的重大更新，所以咱们认为使用它不会冒很大的风险。难以想象的是，npm​@5.8.1 使咱们在 6.0.0 发布以前测试过的版本，在咱们许多开发工程师的机器上（OS X Sierra/High Sierra，node​@v8.9.3）安装依赖失败了，出现了许多错误（好比 cb() never called!）。

速度

咱们很高兴地发现，在每一个包管理器试用五个案例后，npm的平均成绩与 Yarn 至关：

• Yarn：$ rm -rf node_modules && time yarn：126s
• npm：$ rm -rf node_modules && time npm i：132s

在正确的方向上迈出了正确的一步。咱们的试验还会继续 :)。

Locking

npm 在 npm@​5.0.0 引入了 package-lock.json 等价于 Yarn 中的 yarn.lock。npm shrinkwrap 仍然能够被用于建立 npm-shrinkwrap.json 文件，可是根据 npm 文档的描述，这些文件的使用场景有了一些不一样：

推荐的 npm-shrinkwrap.json 使用场景是经过发布过程在注册表中部署的应用程序：例如，用做全局安装或 devDependencies 的守护程序和命令行工具。对于库做者发布这个文件很是不鼓励，由于这会阻止最终用户控制传递依赖关系更新。

另外一方面，package-lock.json 文件不跟随包一块儿发布。这至关于 Yarn 如何不尊重依赖关系的 yarn.lock 文件 —— 父项目管理本身的依赖关系和子依赖关系（但要注意的是，若是库的确在不该该的时候发布 npm-shrinkwrap.json 文件,那么您将不得不使用它们的依赖性）。

Locking 验证

npm 没有与 Yarn 的 yarn check 相对应的功能，但 yarn check 看起来像一些人（如 Airbnb）使用 npm ls> / dev / null 来检查安装错误，如缺乏软件包。

不幸的是，检查将 peer 依赖警告视为错误，这使得咱们没法使用它，由于咱们常常经过 CDN 实现 peer 依赖关系。

npm 最近引入了 npm ci，很幸运它提供了一些验证功能。npm ci 确保了 package-lock.json 和 package.json 在同一验证形式下是同步的。它一样提供了一些其它好处 —— 查看文档了解更多。

以前在使用 npm 时，咱们从未意识到 install 的不一致性（彷佛只有 Yarn 有这些问题 :)），所以咱们认为只使用 npm ci 是安全的。

使用 Yarn 的烦恼

除了追上 Yarn 的速度和拥有 Yarn 依赖关系锁定的保证以外，npm 彷佛没有任何使用 Yarn 时困扰咱们的问题！

Check, check, check

npm​@6.0.0 为咱们检查了全部的盒子，因此咱们决定之后继续使用它！

在对咱们的一个服务进行为期三周的试验成功后，咱们将剩余的其它服务和项目也迁移到了 npm！

建议

deyarn

咱们已经发布了一个叫作 deyarn 的开源模块，它能够帮助你将项目从 Yarn 迁移到 npm。

经过 engines 强制使用 npm

咱们推荐使用 engines 选项，它可让你避免在应该使用 npm 的时候却意外地使用了 Yarn 了。

咱们已经添加了一个配置以下：

{
    "engines": {
    "yarn": "NO LONGER USED - Please use npm"
    }
}
复制代码

对于咱们内部项目的全部的 package.json 而言。deyarn（连接在上方给出）会帮你管理 :)。

试试它！

咱们测试过这个工做流可以知足咱们的需求，而且咱们也推荐你使用它。若是你须要一个极致快速的包管理器，而后你会发现 Yarn 仍然是最佳之选。可是若是你须要一个创建起来比较简单的包管理器，咱们发现 npm 6 在速度与可靠性上保持了很好的平衡。

想要帮助咱们使用 npm 创建将来的社区吗？

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。