-
version字段
-
版本号需要符合semver(语义化版本号)规则，具体版本格式为：主版本号.次版本号.修订号， 如1.1.0。
- 主版本号(major)：做了不兼容的 API 修改
- 次版本号(minor)：做了向下兼容的功能性新增
- 修订号(patch)：做了向下兼容的问题修正
-
当有一些先行版本需要发布时，可以在主版本号.次版本号.修订号之后加上一个中划线和标识符如alpha（内部版本）、beta（公测版本）、rc（候选版本）等来表明。 以vue的版本为例：
- 最新的稳定版本：3.0.5
- 最新的rc版本：3.0.0-rc.13
- 最新的beta版本：3.0.0-beta.24
- 最新的alpha版本：3.0.0-alpha.13
-
可以通过npm install semver来检查一个包的命名是否符合semver规则。
-
~version
-
大概匹配某个版本
-
如果minor版本号指定了，那么minor版本号不变，而patch版本号任意
-
如果minor和patch版本号未指定，那么minor和patch版本号任意
- 如：~1.1.2，表示>=1.1.2 <1.2.0，可以是1.1.2，1.1.3，1.1.4，.....，1.1.n
- 如：~1.1，表示>=1.1.0 <1.2.0，可以是同上
- 如：~1，表示>=1.0.0 <2.0.0，可以是1.0.0，1.0.1，1.0.2，.....，1.0.n，1.1.n，1.2.n，.....，1.n.n
-
^version
-
兼容某个版本
-
版本号中最左边的非0数字的右侧可以任意
-
如果缺少某个版本号，则这个版本号的位置可以任意
- 如：^1.1.2 ，表示>=1.1.2 <2.0.0，可以是1.1.2，1.1.3，.....，1.1.n，1.2.n，.....，1.n.n
- 如：^0.2.3 ，表示>=0.2.3 <0.3.0，可以是0.2.3，0.2.4，.....，0.2.n
- 如：^0.0，表示 >=0.0.0 <0.1.0，可以是0.0.0，0.0.1，.....，0.0.n
- 对于npm，package.json文件可以看成它的输入，node_modules可以做为它的输出。在理想情况下，npm应该是一个纯函数，无论何时执行相同的package.json文件都应该产生完全相同的node_modules树。在一些情况下，这确实可以做到。但是在大多情况下，都实现不了。主要有以下几个原因：
- 使用者的npm版本有可能不同，不同的npm版本有着不同的安装算法
- 自上次安装之后，有些符合semver-range的包已经有新的版本发布。这样再有别人安装的时候，会安装符合要求的最新版本。比如引入vue包：vue:^2.6.1。A小伙伴下载的时候是2.6.1，过一阵有另一个小伙伴B入职在安装包的时候，vue已经升级到2.6.2，这样npm就会下载2.6.2的包安装在他的本地
- 针对第二点，一个解决办法是固定自己引入的包的版本，但是通常我们不会这么做。即使这样做了，也只能保证自己引入的包版本固定，也无法保证包的依赖的升级。比如vue其中的一个依赖lodash，lodash：^4.17.4，A下载的是4.17.4, B下载的时候有可能已经升级到了4.17.21
- 为了解决上述问题，npm5.x开始增加了package-lock.json文件。每当npm install执行的时候，npm都会产生或者更新package-lock.json文件。package-lock.json文件的作用就是锁定当前的依赖安装结构，与node_modules中下所有包的树状结构一一对应。
- 有了这个***-lock.json文件，就能保证团队每个人安装的包版本都是相同的，不会出现有些包升级造成我这好使别人那不好使的兼容性问题。