【经验分享】前端项目由于package.json，bower.json中依赖包版本号引发的问题

新款mbp镇楼 !

起因

某天发生一件比较奇怪的事情，从git上clone下来的代码，执行完npm install && bower install之后，app不能正常工作。

分析

根据报错信息发现是angular出了些莫明奇妙的错误，而同样版本的代码，在上个月setup在同一台机器上另外一个目录是可以work的。我大致推断出，可能是依赖的第三方包冲突了，查了下昨天angular确实发布了新版本1.6.0，我打开bower_components/angular/package.json 中的version字段，确实被升级成1.6.0了，而可以work的那个目录下的angular由于是上个月安装的所以版本号是1.5.8。我把angular的版本退回了1.5.8就可以正常work了。

深入分析

所以说第三方包的日常更新，很可能会影响到我们项目的运行。打开根目录下的package.json或者bower.json我们会在dependencies中找到各个依赖包的名字和版本号定义，一般情况下这个版本号大致有以下3种套路

"dependencies": {
    "angular":"^1.4.10"
    }

"dependencies": {
    "angular":"~1.4.10"
    }

"dependencies": {
    "angular":"1.4.10"
    }

说到这里就要提一下版本号的一种定义规则叫做Semantic Versioning

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

而 ^ 和 ～ 的作用就是用来控制install时候选择版本的策略

• "angular":"^1.4.10" 意味着，本次安装会选择GitHub 上angular 1.x.x版本中最高的版本，即使angular的最新版本是2.x.x,不会去升级主版本号，但是谁挑选此版本号中最高的装

• "angular":"~1.4.10" 意味着， 本次安装会选择GitHub 上angular 1.4.x 版本中最高的版本，比如1.4.20 不会去升级主版本号和次版本号

• "angular":"1.4.10" 就是写死了，每次都是固定版本。

由于package.json ／ bower.json很多地方都是用了^策略，所以当次版本号改变时，往往是比较大的更新，很有可能会引发冲突。

正题

铺垫了这么多，终于要步入正题了。辣么，如果这类问题发生了我们该如何去排错呢，这里就要给大家安利一款本人写的vscode插件，叫做 library-version，它可以方便的把项目下node_moudules / bower_components下所有依赖包的版本号统一列出来，不需要你一个个点开各自的pacakge.json文件去查找了。是不是很有用？把前后2份生成的version list对比一下就知道哪些包被升级了，从而开始着手排查问题，或者从新制定安装策略。

关于插件library-version

最后希望大家帮忙安装下，帮我increase一下download count
如果大家对这款插件的开发有兴趣，我有时间也会另开一篇文章来讲讲这个插件的实现思路。
插件可以直接使用你的vscode安装，搜library-version
marketplace地址：https://marketplace.visualstu...
github地址： https://github.com/momoko8443...

后续 2017.01.08 更新

根据评论中同学的推荐，使用了yarn这个包管理工具，这个工具会在第一次执行的install的时候生成一份yarn.lock文件，里面就锁定了依赖包的具体版本，如果以后在其它路径下再按装的话，如果include了之前的yarn.lock文件，那么就会严格按照之前的版本去安装依赖包，而不会根据Semantic规则去自动升级包了。

另外，今天也在另外个team的node工程里看到一个npm-shrinkwrap.json的文件，我好奇打开一看发现里面的配置和yarn.lock的配置大同小异，心想会不会npm install的时候也有类似lock版本号的功能，于是查了下npm的doc发现，确实是有的，参见 npm-shrinkwrap 不过这个生成lock文件的功能需要自己手动执行 npm shrinkwrap。