那些年使用npm进行依赖管理所踩的坑

那些年使用npm进行依赖管理所踩的坑

废话

公司的项目用上了node来作先后端分离，相应的天然离不开使用npm来对依赖的第三方包进行管理。

npm使用的语义化版本号管理想法很好，使用 npm install --save 安装依赖包时，自动加上的 ^x.x.x 的版本号，看上去彷佛也颇有道理。

然而现实老是那么残酷，在经历了屡次：在开发环境还跑的好好的项目，提测和上线时就挂了的状况后（此处省略一万字），
我终于意识到，版本号仍是固定的好啊！！！

固然，依赖包的版本号应该怎么固定，仍是有讲究的。
去掉 ^x.x.x 前面的 ^ 使用一个固定的版本当然能够，但经过 npm shrinkwrap 来固定，我以为更加合适。

使用 npm-shrinkwrap

关于 npm-shrinkwrap 的介绍就很少说了，网上一搜一大堆。
反正就是生成一个版本信息固定的 npm-shrinkwrap.json 文件，而后 npm 在安装依赖包的时候会首先参考 npm-shrinkwrap.json 文件的设置。

本觉得万事ok，没想到却在生成 npm-shrinkwrap.json 文件的时候踩了坑……

问题

项目里面有 dependencies 包 T，T 又 dependencies 包 C。然而在服务器上安装好，运行的时候却恰恰提示少了 C。
因而打开 npm-shrinkwrap.json 一看，里面的 T 依赖的 C 不见了！WTF！

通过一番排查，真想终于水落石出。原来项目有 devDependencies C。
开发的时候 npm insatll，T 里面的 C 就被省略掉了。
本来贴心的处理，却在 npm-shrinkwrap 成了一个大坑，由于 npm-shrinkwrap 默认是根据当前已安装的 dependencies 的目录结构来生成的。

解决

知道了问题的缘由，解决起来天然就很轻松了。
咱们在须要 npm-shrinkwrap 的时候：

方法1：清空 node_modules ，而后 npm install --production ，而后再 npm shrinkwrap

方法2：npm prune --production ，而后再 npm shrinkwrap --dev

后话

npm 使用的版本为 v2。 v3 彷佛由于会去计算依赖，没有此问题了。
另外，一个心得是，对依赖的管理，要使用 npm 提供的方法来管理。
好比，我想去掉已安装的 devDependencies 包，应该使用 npm prune --production 而不是本身手动的使用 npm uninstall 。