在学习WEBPACK整合开发的过程中,看到别人的项目里有个NPM-SHRINKWRAP.JSON的配置文件,打开后发现里面主要是一些包的版本配置信息。
那么,在已经有了PACKAGE.JSON的DEPENDENCIES字段配置依赖关系的情况下,为什么还需要SHINKWRAP呢?
查阅后发现,这是由于以下两点原因:
1.npm 建议使用 semver 的应用程序版本,但这也完全依赖第三方包遵守这一规则。如果你依赖于的包不遵循 semver ,或者依赖的包的新版本有重大更改(而你使用了 ^
的宽泛版本安装),这潜在可能是会导致问题的。
所谓SEMVER,指的是语义化版本,其规则概述如下:
版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
- )主版本号:当你做了不兼容的 API 修改,
- )次版本号:当你做了向下兼容的功能性新增,
- )修订号:当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
2.另一个问题的出现是由于 npm 安装依赖的机制。npm 的安装包是有层次结构的,手动控制要安装的软件包的版本号可以实现,但是你只能在
package.json 使用精确的版本号控制你的直接依赖包,但那些多层以上的依赖就没办法控制了;一个第三方包不严谨的版本依赖生命可能破坏你的依赖管理。
3.在开发阶段执行得到的版本,和后续部署时得到的可能是不一致的,更不可控的是,你依赖的第三方包也有这样的情况会导致潜在的上线风险。
使用SHRINKWRAP就可以很好的解决上述问题,在NPM INSTALL的时候,会先检测项目中是否有SHIRNK-WRAP.JSON文件,如果有则会使用该文件的版本信息而非PACKAGE.JSON的信息。
参考文献:
http://www.tuicool.com/articles/EBVNV37
http://semver.org/lang/zh-CN/