X.Y.Z
semver 语义化版本。
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
版本号前面符号的意义
npm 5 版本以后对于依赖会采用扁平化管理，简单说会收集当前项目/库所有的依赖库，形成一个资源表，根据依赖规则下载依赖文件，放置 node_modules 文件夹下。如果对同一个依赖有不同版本的情况，根据规则选择合适的放置 node_modules 根目录，冲突版本放置库的 node_modules 文件夹内。
大概的目录结构
|-- node_modules
|--|-- base@1.1.1
|--|-- lib1@1.1.0
|--|-- lib2@1.0.1
|--|--|-- node_modules
|--|--|--|-- base@0.1.0
|--|-- lib3@1.0.0
|-- package.json
同样依赖 base 库，但是版本不一致。
没有任何符号
1.0.0
完全百分百匹配，当前库/项目必须使用当前版本号，如果和其他依赖使用了相同库不同版本，会在库的文件夹下建立一个 node_modules 文件夹存放它需要依赖的版本文件。
>、>=、<、<=
>1.0.0
必须大于某个版本，例如，可以使用 1.0.1、1.1.1 、2.0.0 的版本。
>=1.0.0
必须大于或等于某个版本，例如，可以使用 1.0.0、1.0.1、1.1.1 、2.0.0 的版本。
< 1.0.0
<=1.0.0
小于、小于等于参考大于、大于等于。
~
~1.0.0
不改变大版本号和次要版本号，小版本号随意，例如，可以使用 1.0.1、1.0.3 的版本，版本号保持 1.0.x 格式就可以通用。
^
^1.0.0
版本号最左边非 0 数字的右侧可以任意，例如，可以使用 1.0.1、1.2.0 的版本，版本号保持 1.x.x 格式就可以通用。
x
1.0.x 或 1.x
x 的位置即后面表示任意版本，例如，可以使用 1.0.2/1.11.1 的版本。
*
“base”: “*”
任意版本。
–
“base”: “1.0.1-1.5.9”
在这两个版本号之间的版本可以通用。
||
“base”: “1.1.1||^2.1.1”
多个版本规则都适用。
注意点
在初次安装依赖的时候，npm 会生成一个 package-lock.json 文件，yarn 生成一个 yarn.lock 文件，把当前时间点的依赖关系固定，就算删除 node_modules 也不会改变。
如果项目/库更改了依赖的版本，最好删除两个锁定文件重新安装，如果不，会出现依赖关系错乱，在原依赖内生成不必要的文件。
例如 lib1 依赖 'base':'^1.1.0'，项目依赖 'base':'1.2.0'，初次安装会在 node_modules 根目录放置 base 库。
手动改变项目依赖 'base':'1.7.0'，直接安装依赖，这时候 lib1 文件夹内会有一个独立的 base@1.2.0 的版本。这是因为锁版本文件以及预置了 lib1 当前依赖关系，并不是每次都会动态变更。
如果使用非固定模式，如果远程仓库更新/高版本，会默认采用能匹配到的最新版本号。非固定和固定模式搭配容易出现依赖中带有私有版本的文件。
转载请注明：OnlyLing - Web 前端开发者 » NPM 依赖库版本号、符号