为什么要检查凉亭组件？答案

【问题标题】：Why check in bower components?为什么要检查凉亭组件？
【发布时间】：2013-06-15 16:48:51
【问题描述】：

Bower 文档说

注意如果您创作的包不打算供其他人使用（例如，您正在构建 Web 应用程序），则应始终将已安装的包签入源代码管理。

有人对为什么有一个很好的答案吗？

如果我正在制作一个网络应用程序，我不希望我的存储库中充斥着库 X 版本的更新。

我只想更新 bower.json 依赖项。我认为大多数项目都会有一个构建步骤或类似的步骤，例如 grunt。构建步骤将确保在构建之前调用 bower install/update，以便这些文件存在用于 concat/minification 等。甚至是某个 dist 文件夹的纯副本。

我错过了什么吗？

【问题讨论】：

标签： bower

【解决方案1】：

这是为了锁定您的依赖项，以防止错误的依赖项破坏您的应用程序或远程关闭阻止部署。即使您有构建步骤，也可能发生这种情况，因为您可能没有对每个构建进行彻底测试，并且自动化测试无法捕获所有内容，尤其是视觉回归。此外，多个开发人员可能具有不同版本的依赖项。通过提交依赖项，您可以确保每个人都使用相同的版本。我还发现查看差异是确保在依赖树中没有引入任何恶意的好方法。

在 Node 世界中，npm shrinkwrap 部分解决了这个问题，但还没有进行校验和匹配。 Bower 目前有一个开放的ticket 来实现相同的功能。

您可以在这篇博文中了解更多信息：Checking in front-end dependencies

【讨论】：

是的，我想我可以使用 1.2.3 而不是 ~1.2.3 或类似的。（或者，如果我相信图书馆使用 semver，那也没关系）但我想如果图书馆 X 在它的 bower.json 中对图书馆 Y 有依赖并使用 >=2.3.4 或类似的东西，那么我就有麻烦了。期待收缩包装功能。
是的，锁定版本，即使是深度，也不够，因为标签和版本可以被覆盖。这就是为什么npm shrinkwrap 需要对 deps 进行校验和匹配，这也是我们从一开始就希望在 Bower shrinkwrap 中实现的。
这和游戏开发的道理是一样的。您不会一直升级软件包，因此在特定版本中冻结或“收缩包装”它们是有意义的，以防止部署或构建延迟。

【解决方案2】：

这个答案是非技术性的，但却是不检查 Bower 组件的实际原因。

我宁愿建议将 bower 包锁定在 bower.json 中，而不是签入这些包。因为相信我，你不可能在一台电脑上下载和解压成千上万的文件。性能缓慢的计算机存在文件路径非常大和深的问题。在这个互联网世界中，我相信下载软件包总是很容易，而不是随身携带。

这只是一个偏好问题。这一切都来自经验。我在 Github 上签入了一个带有 bower 组件的项目，上传和下载时情况更糟。我是通过相对较新的 Mac 完成的。

【讨论】：