使用bower可能会遇到的5个问题

bower是业界使用率比较高的前端组件管理工具，基本上类似于npm，但解决了项目中同一个库的引入多个版本的问题。大家知道，同一个库版本并存这对于node来说很正常，但对于浏览器来说几乎是不可接受的。以下是我们使用bower遇到的5个问题和我们的取舍与选择。

一、组件版本用master 还是 tag？

新组件在快速迭代、小范围使用的情况下推荐用master
其他情况使用tag，上面代码段里的v0.0.5就是tag的版本号。

{                                       
  ...
  "dependencies": {
    "pop": "[e-mail]:bower_components/pop.git#v0.0.5",
    "loader": "[e-mail]:bower_components/loader.git#v1.1.0",
    "youzanjsbridge": "[e-mail]:bower_components/youzanjsbridge.git#v0.0.3"
    ...
  }
  ...
}

二、我要稳定：发现版本不一致怎么办？

可以在数字前面加!，让这个选择固定到bower.json里，下次别人执行bower update 就会直接选择你选定的版本了。

如下图：再一次执行bower udpate 就自动选择了之前固定下来的版本了。

三、如何把所有组件更新到最新版？

可以安装个工具 bower-update：

npm install bower-update -g

在工程目录里执行bower-update后会挨个让你确认要不要把某个组件升级到最新版本，最后你的选择会被写到bower.json里。

四、版本号必须以 v 打头么？

经测试，bower对tag的版本号里开头的 v 是做了自适应的，比如：

假设
远程服务器上有2个版本的tag，分布是 v0.0.1 和 0.0.2
那么本地bower.json里
如果要使用0.0.1版本，无论指定版本号为“#0.0.1” 还是 “#v0.0.1”
如果要使用0.0.2版本，无论指定版本号为“#0.0.2” 还是 “#v0.0.2”
都是可以的并且能下到正确的代码

五、bower组件代码的升级迭代如何管理

我们的经验是：
1、组件尽量拆分地细粒度，一个组件或者一类组件放在一个git仓库里

2、相近范畴和功能的组件在一个git仓库里

3、每个git仓库由一两个人主要维护（在gitlab里的话就是给他设master权限），其他人要改代码，需要提交pull request，由负责维护的人审查代码，合并代码并拉新的tag出来

我们发现 gitlab 里 develop 权限的用户也能自己拉 tag（要命的是我们还没发现如何禁止这个操作），解决有人提了一个分支上来，没等维护的人合并就基于这个分支拉了个tag出来，自己很欢快的用起来了。实际上这么玩会有很大的坑的，所以需要团队内部需要做一个约定：只有维护的人才可以拉tag。

补充下为什么说随便拉tag会有坑——举个例子：项目X是A在维护的，B提交了一个分支并发起一个pull request，没等A接受这个pull request拉出新tag，B直接基于自己的hotfix拉的tag，其他人依赖这个新tag提供的接口写了些代码。然后A觉得B的这个pull request是有问题的，没有接受，于是很可能后面从master新拉的 tag 不包含这部分接口。于是就出现了 0.1.2 版本不兼容 0.1.1 版本的情形。

本文首发于我的
SegmentFault专栏：http://segmentfault.com/a/1190000004189341
个人技术博客：http://delai.me/code/bower/
转载请注明出处