Npm 5 package locks

上一篇文章中提到了几个前端界的版本大佬，这不，上个月 Node 又发布了 8.0 版本。

Node 8 这次升级有哪些令人眼前一亮的新特性？

• 新增了 Node.js API (N-API)
• 新增了 util.promisify()，用于将原有的 callback 形式的函数 Promise 化（相信是个神器...）

不过，这些都不是今天的重点，今天的主角另有其人。

Npm 5

最近，正好有一个小项目需要用到 node 服务，也就正好升级一波尝尝鲜。

Node 的升级通常会伴随着 npm 的升级，这次也没有例外。升级至 node 8 以后，npm 也自动升级至了 5。

一开始也没有在意，但当安装完依赖之后，我们的主角登场了...

项目下面多了一个文件 package-lock.json。

心中瞬间迸发出一个想法：窝艹，这不是 yarn 嘛~

赶紧学习一波看看。

这不看不知道，一看才发现这次 npm 5 还是有着许多的变化。

首先，重写了 cache，不推荐手动清除 npm cache。以前那种安装不成功，跑下 npm cache clean，再来一次的日子一去不复返了~

其次，一个小帮助。现在 install 后，会将依赖直接添加到 package.json 文件中，也就是默认添加 --save 参数。

最大的变化就是引入了 package lock 这个新特性。剩下一些没用到过，也就不乱说了。

Npm package locks

相信童鞋们多多少少遇到过，一个项目在自己机器上跑得好好的，又来一个新同事，或另一台机器安装项目就跑出问题的情况。调查了半天发现，原来是某个依赖包安装的版本不一致引起的。这或许可以怪你，谁让你不在 package.json 里把版本号定死的。（定死版本号同样也会带来升级库文件不方便的问题。）

以后，你就不必再为此操心了。因为，npm 引入了 package locks。

Npm 5 之后使用 npm install，npm 不再是直接根据 package.json 中定义的依赖版本进行安装，而是先去尝试查看 package-lock.json 文件。如果 package-lock.json 文件不存在，则仍像之前一样按 package.json 安装，并同时自动生成 package-lock.json 文件。反之，则就根据文件中保存的依赖版本信息进行安装。

这样就能保证，每次安装都会得到相同的依赖树，也就再也不会发生之前那种情况了。

package-lock.json

package-lock.json 是一个安装依赖时，由 npm 自动生成的一个文件，里面保存的是依赖的版本信息，以及依赖之间的树状关系。当所安装的依赖不存在于 package-lock.json 文件中时，npm 会自动修改该文件。

既然，它用于记录依赖树，那么，为了保证团队各成员之间使用相同的依赖树，它需要被提交到代码仓库。与此同时，它的改动也代表了项目依赖版本的改动，同样 npm 建议将 package-lock.json 的修改单独进行提交。

除此以外，使用 package-lock.json 还需注意以下几点：

• 只能存放于项目根目录，其他位置无效
• 不随包一同发布
• 与 npm-shrinkwrap.json 同时使用时，npm-shrinkwrap.json 优先级更高

提到了 npm-shrinkwrap.json，自然也要了解一下。

npm-shrinkwrap.json

npm-shrinkwrap.json 是通过命令 npm shrinkwrap 生成。

它与 package-lock.json 有着同样的数据结构。不同之处在于，它没有刚刚 package-lock.json 所提到的这些限制。

所以，npm-shrinkwrap.json 的使用场景是用于定义发布包所需的确切依赖版本信息。与之相反，package-lock.json 的使用场景就是用于定义协同开发时，项目所安装的依赖版本信息。

最后，还是强烈推荐将 node 升级到 8，这样就能用到 npm package locks 这个功能啦。

PS: 快写完了发现一篇相同主题的好文：npm5 新版功能特性解析及与 yarn 评测对比。（和大佬一比，高下立见?还是要多学习...）

7 月都不知道干了点啥，忙忙碌碌地就过了...（差点就坏了规矩，警醒~）

首发于个人博客，欢迎订阅。