Bower版本控制的最佳实践？

Question

我想知道如何确保我在未来使用Bower版本配置不会出问题？ 例如，我已经涉及多个项目，其中一些要求使用

">=1.0.0"
"~1.0.0"

据我所知，Afaik是指

">=" tells that all versions above 1.0.0 are fine
"~"  tells all versions/minor updates on 1.0.x are fine

更具体地说：

"dependencies": {
  "angular": ">=1.3.0",
  "bootstrap": ">=3.2.0",
  "jquery": "~2.1.0",
}

编写这段代码时，以下版本配置已包含：

angular:   1.3.1
bootstrap: 3.2.0
jquery: 2.1.0

今天您将获得以下内容:

angular:   1.4.0
bootstrap: 3.3.4
jquery: 2.1.4

从开发者整合库的角度来看，这些功能在开发初期是很好的。您无需与痛苦的依赖管理和版本混淆。但是，一旦进行测试，版本应该固定为定义的版本。

我已经接触过多个项目，在短短的3个月内就出现了问题，因为库被更新到不同的版本，这些版本要么彼此不兼容，要么某些功能失效。因此，构建可能不再工作，甚至更糟糕的是，客户端可能会出现问题。

如何最好地解决长期项目中的版本问题？

- cilap

---

没有其他人遇到同样的问题吗？ - cilap

Answer 1

目前如果您唯一的选择是bower，那么没有锁定文件。然而，类似于composer的锁定文件或npm的shrinkwrap机制正在进行中，但由于当前没有足够的贡献者/维护者来测试该功能并长期维护它，因此似乎已经停滞不前。

更新：
由于我们现在有yarn，您可以选择使用它，它使用锁定文件机制作为默认行为。唯一的注意事项是它使用npm注册表，这意味着某些包可能尚未在那里注册，或者已经像Google的Polymer一样被命名空间化，您可能需要注意。

- Hayko Koryun

---

Composer的lockfile选项看起来很不错。Bower锁定问题现在已经将近1年了...所以没有太多关注。 - cilap

Answer 2

我的get-t-go方法是使用精确版本， 不要让你的依赖工具决定什么版本最适合你，因为他们（和其他人）通常是错误的。

我的意思是，我在bower上已经看到了足够多的情况。有一天你得到版本A.B.C，第二天你可能得到A.D.F，而A.D.F会与你拥有的某些其他依赖项发生冲突。这可能会引入各种问题。

最好的方法是自己处理所有升级并进行测试。 我还没有看到过一个项目，在这个项目中UI和javascript测试是以可靠的方式自动化完成的。

- R. van Twisk