npm如何管理依赖包的版本
在写项目的时候遇到了一个依赖包的版本问题，所以在这里把它记录下来。
问题描述：在本地开发的时候使用element-ui InputNumber组件的precision属性，在本地开发的时候是好的，然后提测了发现这个precision属性并没有起作用。
出现这种问题的几种可能：
- 测试环境的代码没有更新；
- 测试环境的InputNumber组件的没有这个precision属性；
然后查看测试环境的代码，发现和本地代码是一样的。那么造成的上面这种可能就是precision属性问题了。查了测试环境element-ui的版本是2.3.*的版本，然后看了element-ui的更新日志InputNumber组件的precision属性是在2.4.0版本的时候新增的属性。所以测试环境InputNumber组件的没有这个precision属性，故不起作用。为什么我本地是好的呢，因为不知道在什么时候我又重新安装了依赖包，所以我本地的element-ui的版本是2.4.*的版本。
出现这种问题后，为了避免再次出现这种问题，在想怎样实现锁定依赖包的版本号。
下面将介绍npm如何管理项目依赖包的版本：
- 介绍语义化版本号
- 回避最优版本号解决版本不一致问题
- 使用
npm shrinkwrap解决版本不一致问题 - 本地安装优于全局安装
语义化版本号
npm默认所有的Node包都使用语义化版本号，这是一套指导开发人员如何增长版本号的规则，要求：
- 每个版本号都形如：1.2.3，有三部分组成，依次叫‘主版本号’、‘次版本号’、‘修订号’；
- 当新版本无法兼容基于前一版本的代码时，则提高主版本号；
- 当新版本新增了功能和特性，但仍兼容前一版本的代码时，则提高次版本号；
- 当新版本仅仅修正了漏洞或者增强了效率，仍然兼容前一版本代码，则提高修订号；
默认情况下，npm install --save下载的都是最新版本，并且会在package.json文件里登记一个最优版本号。我们在看package.json文件时，可能会看到这两种情况^2.4.0和~2.4.1，最优版本号在数字之前多出了一个“标记”，^意味着下载的包可能会是更高的次版本号或者修订版本号，而~意味着有可能会有更高的修订版本号。
如果想要保证用户和其他开发人员下载的依赖包与我们的代码兼容，那么可以用下面两种办法来锁定项目的依赖包版本号。
回避最优版本号
最简单快捷的方法，就是不使用最优颁布号。对于记录在package.json里的版本号，只需要把标记^和~去掉即可。这个方法虽然简单，但是有个缺陷：无法锁定次级依赖的版本号。比如说你的项目依赖某个特定版本的element-ui，你可以按照上面的方法在
package.json里去掉最优版本的标记。
而这个版本的element-ui有自己的package.json，里面记录的依赖包使用的很可能还是最优版本号。那么这样就有点复杂了。
使用npm shrinkwrap命令
现在的问题关键在与如何锁定依赖之依赖的版本号。npm有一个指令来解决这个问题：npm shrinkwrap。
在你开发项目时，进行到某个节点，一切都运行的顺利，说明目前所有的依赖包和你的代码兼容的很好。这个时候，你就可以在你项目文件夹下运行上面这个命令。它会生成一个npm-shrinkwrap.json文件，记录目前所有依赖包（及更底层依赖包）的版本信息。这样当以后其他人运行npm install命令时，npm首先会找到npm-shrinkwrap.json文件，依照其中的信息准确的安装每一个依赖包，只有当这个文件不存在时，npm才会使用package.json。
本地安装优于全局安装
npm安装依赖包时有两种模式：本地安装和全局安装。本地安装表示依赖包会被下载到当前项目的node_modules文件里，而全局安装则会把他安装到系统级别的目录里。
