npm shrinkwrap的用途

在学习WEBPACK整合开发的过程中，看到别人的项目里有个NPM-SHRINKWRAP.JSON的配置文件，打开后发现里面主要是一些包的版本配置信息。

那么，在已经有了PACKAGE.JSON的DEPENDENCIES字段配置依赖关系的情况下，为什么还需要SHINKWRAP呢？

查阅后发现，这是由于以下两点原因：

1.npm 建议使用 semver 的应用程序版本，但这也完全依赖第三方包遵守这一规则。如果你依赖于的包不遵循 semver ，或者依赖的包的新版本有重大更改（而你使用了 ^ 的宽泛版本安装），这潜在可能是会导致问题的。

所谓SEMVER，指的是语义化版本，其规则概述如下：

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

1. )主版本号：当你做了不兼容的 API 修改，
2. )次版本号：当你做了向下兼容的功能性新增，
3. )修订号：当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

2.另一个问题的出现是由于 npm 安装依赖的机制。npm 的安装包是有层次结构的，手动控制要安装的软件包的版本号可以实现，但是你只能在 package.json 使用精确的版本号控制你的直接依赖包，但那些多层以上的依赖就没办法控制了；一个第三方包不严谨的版本依赖生命可能破坏你的依赖管理。

这一点也很好理解，你的PACKAGE.JSON里写的是你的项目的直接依赖包，而这些依赖包又有各自的依赖包，在PACKAGE.JSON里就不受你的控制了。

3.在开发阶段执行得到的版本，和后续部署时得到的可能是不一致的，更不可控的是，你依赖的第三方包也有这样的情况会导致潜在的上线风险。

使用SHRINKWRAP就可以很好的解决上述问题，在NPM INSTALL的时候，会先检测项目中是否有SHIRNK-WRAP.JSON文件，如果有则会使用该文件的版本信息而非PACKAGE.JSON的信息。

参考文献：

http://www.tuicool.com/articles/EBVNV37

http://semver.org/lang/zh-CN/