是否可以将 yarn 视为替代 bower 和 npm 的可行选择？

Question

我应该澄清一下，我对前端工具的经验并不丰富，所以如果我问的是明显和愚蠢的问题，我很抱歉。

到目前为止，我一直将 bower 用于前端，将 npm 用于服务器端，尽管提到的每个工具都有其优点，我指的是 的 平面依赖管理 bower（减少来自客户端的负载）和 npm 的 嵌套依赖管理（有助于版本控制），使用这么多工具（webpack 、浏览器化等）。我可能一直在以错误的方式使用这些工具，并且可以通过某些选项（我不知道）使用它们中的任何一个，并且只触及表面，我只是将这个 answer 作为我的经验法则并拥有自从我读过它以来就一直这样做。如果我能至少将这两个减为一就好了。

最近我对 yarn 产生了好奇，随着围绕它的所有炒作，似乎它一直做得很好，好像它将完全取代 npm。当我阅读文档时，我发现了 --flat 选项，这让我想知道是否也可以将它用作凉亭替代品？如果是这样，这是否意味着我可以拥有平面或嵌套的依赖管理器（只需为后端和前端拥有多个 JSON 文件）？

如果有人能指出我正确的方向，我将不胜感激！

Answer 1

这取决于您的具体用例，但...可能。

目前，主要趋势似乎是向 Webpack 和 Browserify（因此是 npm 或 Yarn）之类的模块打包器和远离 Bower 的方向发展。您可以在 NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack 阅读有关情况的精彩概述，以及您可能想要 Webpack 而不是 Bower 的一些原因。

目前，您可能正在使用 HTTP，在这种情况下，拥有一个 JavaScript 捆绑文件而不是大量源文件（就像 Bower 会发生的那样）更快。这就是 Webpack 和 Browserify 如此受欢迎的原因（以及其他原因）——它们应该提高性能并大大简化开发。

旁注：HTTP/2 会降低模块捆绑的价值，因为多个请求的成本会大大降低。有关涉及 HTTP/2 的问题的更详细说明，请参阅 What is the value of using Webpack with HTTP/2。

如果你使用 npm 或 Yarn，依赖项是否嵌套并不重要——你的前端依赖项无论如何都会与 Webpack/Browserify 捆绑在一起，因此使用嵌套包的主要成本是它占用更多空间和更多的下载时间。

由于npm v3 和 Yarn 可以进行平面安装，所以无论如何都不应该有任何问题。简而言之：您可能可以做到，而且许多其他人正在这样做。

Answer 2

最近几天，Yarn 的受欢迎程度呈上升趋势，这主要是由于与 npm 不同的几件事。

第一，它是 100% 确定性的，也就是说，如果你从任何状态、任何时间、1000 次运行 yarn，它仍然会一直以相同的方式工作。 npm 的安装是不确定的。如果你从不同的状态运行它，它会以不同的方式安装。

Yarn 也做了一些更好的缓存。事实上，它做得很好，您会看到安装时间显着减少。您可以看到大型应用程序的安装时间减少了 10 倍。

默认情况下，Yarn 还会锁定您的依赖项。可以使用 npm shrinkwrap 命令执行此操作，但如果您曾经不得不维护其中一个命令，那可能会很麻烦。