npm5 新版功能特性解析及与 yarn 评测对比

更多腾讯海量技术文章,请关注云加社区:https://cloud.tencent.com/developer/column

作者:马铖

前言

前段时间 npm 发布了 5.0 版本,提供了自动记录依赖树,下载使用强校验,重写缓存系统等功能升级和改造,吸引了不少关注。本文将对 npm5 的新功能和变化点在进行实践使用后进行介绍和总结,并和 yarn 进行简单对比。

更新一览

通过官方的 Release note 我们可以看到 npm5 的主要新功能和大改动主要有下面几点(后面将会详细介绍):

默认新增 package-lock.json 来记录依赖树信息,进行依赖锁定,并使用新的 shrinkwrap 格式。

--save 变成了默认参数,执行 install 依赖包时默认都会带上,除非加上 --no-save。

Git 依赖优化:支持指定 semver 版本安装;含有 prepare 脚本时将安装其 devDependencies 并执行脚本。

使用本地目录文件作为 file 类型依赖安装时,使用创建 symlink 的方式替代原来的文件拷贝方式,提升速度。

脚本更改:在 npm pack, npm publish 时新增 prepack 和 postpack 脚本;preinstall 脚本运行优先级提升到最前,并且可以修改 node_modules。

包发布将同时生成 sha512 和 sha1 校验码,下载依赖时将使用强校验算法。

重写整个缓存系统和 npm cache 系列命令。废除 --cache-min --cache-max 等命令,缓存系统将由 npm 自身维护,无需用户介入。

registry 策略调整:配置优先级高于锁文件中记录的优先级;除非使用不同 scope 的包,不再支持不同的包使用不同的 registry。

除此之外还包含一些细节优化:

离线安装时将不再尝试连接网络,而是降级尝试从缓存中读取,或直接失败。

锁文件(package-lock.json, npm-shrinkwrap.json)将包含 optionalDependencies。

本地包(local tarball)具有 .tar, .tar.gz, 或 .tgz 后缀时才会被安装。

新增 notice 为默认 loglevel。

node-gyp 在 Windows 提供对 node-gyp.cmd 的支持。

移除 ./cli.js,使用 ./bin/npm-cli.js 代替。

下面就来对主要的修改点做详细介绍和对比:

特性一:锁文件(lockfile)

package-lock.json

本次 npm5 新增了 package-lock.json 文件,在操作依赖时默认生成,用于记录和锁定依赖树的信息。使用过 yarn 的同学应该能感觉到,这次 npm5 的很多改动都有参考 yarn,这里估计也是在 yarn 的 lockfile 大受欢迎的背景下做出了这个修改(其实之前的 npm 版本并不是没有 lockfile,后面会提到)。

在首次执行 npm install 后,会默认创建 package-lock.json 文件。

之后再次 install 将根据此文件中的记录进行安装。

如果对依赖进行了修改(新增依赖、npm update 或 npm install 指定不同版本的包),都将更新记录到此文件中。

npm-shrinkwrap.json

npm5 新增的 package-lock.json 文件和之前通过 npm shrinkwrap 命令生成的 npm-shrinkwrap.json 文件的格式完全相同,文件内记录了版本,来源,树结构等所有依赖的 metadata。需要注意的是 npm shrinkwrap 并不是一个新功能特性,而是从 npm2 就开始有的功能。也就是说在 npm5 之前的版本也是可以通过 shrinkwrap 锁定依赖的。(在这一点上,其实 Facebook 也是早期在使用 npm shrinkwrap 等功能时无法满足需求才导致了现在 yarn 的出现。可以阅读 Facebook 的这篇文章了解他们开发 yarn 的动机。)

而最新的 npm5 在生成了 package-lock.json 之后,再运行 npm shrinkwrap 命令,会发现就是把 package-lock.json 重命名为 npm-shrinkwrap.json 而已。

因此 package-lock.json 表面上看只是把 npm-shrinkwrap.json 作为了默认创建,为何还要新建一个文件呢?官方对于此也给出了答复和解释:新增 package-lock.json 主要是为了使得 npm-shrinkwrap.json 可以向下兼容,保证旧版也可使用(比如已有 shrinkwrap 文件的项目,或是回滚旧版的场景)。另外 package-lock 的名称也比 shrinkwrap 相对更加直观。

具体可以查看 npm 核心开发者在 reddit 上的这篇解释。

除此之外,package-lock.json 和 npm-shrinkwrap.json 在使用场景上也有以下不同点:

package-lock.json 用于开发人员锁定版本使用,应该提交到版本控制,不应该跟随发布。其只在项目顶级有效,放在依赖包中时此文件无效。

npm-shrinkwrap.json 可以作为库的依赖锁进行发布。当依赖包有此文件时,将按照此文件安装其下游依赖。

当两个文件同时存在时,npm-shrinkwrap.json 有高优先级,package-lock.json 文件将被忽略。

已有 npm-shrinkwrap.json 文件时,不会再创建 package-lock.json 文件。

具体规范文档可以参考:

npm-shrinkwrap.json

package-lock.json

npm-package-locks

过渡升级

关于 npm-shrinkwrap.json 文件,还要注意之前的版本是不包括 devDependencies 的,而这次升级 npm5 后 devDependencies 将被包括进来。所以如果使用旧版时已有 npm-shrinkwrap.json 文件,这次升级后再次 install 时会把这些缺少的依赖加进去(npm5 之后会通过 "lockfileVersion" 字段来判断 shrinkwrap 的版本)。因此多人开发时要注意大家同步升级,避免产生新旧混用的情况。

适用场景

综上我们能总结出 package-lock.json 和 npm-shrinkwrap.json 在项目中的适用场景:

开发时提交和使用 package-lock.json 来保证不同环境、人员安装依赖的一致性。

发布包时如果有锁定的需求,可以用 npm shrinkwrap 命令把 package-lock.json 转为 npm-shrinkwrap.json 随包发布。

如果项目中已经在使用 npm-shrinkwrap.json,可以继续使用(但要注意从旧版本升级到 npm5 后 install 时会被更新),其优先级高于 package-lock.json,并且不会再被重复创建。

和 yarn 的差异

手动修改 package.json 依赖版本:

我们已经知道,生成 package-lock.json 后,重复执行 npm install 时将会以其记录的版本来安装。这时如果手动修改 package.json 中的版本,重新安装也不会生效,只能手动执行 npm install 命令指定依赖版本来进行修改。

而这一点 yarn 是可以做到的。猜想 yarn 在执行前是先对比了一遍 package.json 和 yarn.lock 中的版本,如果版本范围完全不符的话会重新安装并更新 lockfile。

registry 优先级:

在 npm5 中,配置的 registry 优先级要高于 lockfile 内记录的 registry 的优先级。如果设置的 registry 和 lockfile 中的不同,将使用设置的 registry 安装(命中缓存时除外)。

这一点也和 yarn 不同。yarn 在有 lockfile 时会完全忽略 config 中的 registry。个人感觉 npm5 的设定更加合理,否则有频繁切换 registry 需求的用户可能会比较难受。

特性二:Git 依赖支持优化

新版本对 Git 依赖支持了通过 semver 版本号安装指定的版本。例如我可以通过以下命令安装 Github 上的 chalk 1.0.0 版本:

npm install git+https://github.com/chalk/chalk.git#semver:1.0.0

这个特性在需要安装大量内部项目(例如在没有自建源的内网开发),或需要使用某些依赖的未发布版本时很有用。在这之前可能需要使用指定 commit_id 的方式来控制版本。

除此之外,这次升级还对 Git 依赖增加了 prepare 脚本的支持。声明 perpare 脚本时,依赖被安装时将会同时安装它的 devDependencies,然后执行脚本。详细可以看开发人员在 twitter 上的这个演示。

特性三:文件依赖优化

在之前的版本,如果将本地目录作为依赖来安装,将会把文件目录作为副本拷贝到 node_modules 中。而在 npm5 中,将改为使用创建 symlinks 的方式来实现(使用本地 tarball 包除外),而不再执行文件拷贝。这将会提升安装速度:

npm install ../packages/mylib npm install file://packages/mylib

有关新的 file:// 规范描述可以参考官方的 file-specifiers。

具体修改和实现可以参考这个 PR。

特性四:缓存优化

新版本重写了整个缓存系统,缓存将由 npm 来全局维护不用用户操心,这点也是在向 yarn 看齐。升级新版后,用户基本没有手动操作 npm cache 的场景。npm cache clean 将必须带上 --force 参数才能执行,并且会收到警告:

--cache-min --cache-max 也已废除。同时在离线安装等场景将会提高缓存使用的优先级,提升安装速度。

速度对比

首次安装

有缓存,有 lockfile 情况重复安装

有缓存,无 lockfile 情况重复安装

无缓存,有 lockfile 情况重复安装

无缓存,无 lockfile 情况重复安装

删除 node_modules,有缓存,有 lockfile 情况安装

删除 node_modules,有缓存,无 lockfile 情况安装

删除 node_modules,无缓存,有 lockfile 情况安装

registry:

npm: https://registry.npm.taobao.org

yarn: https://registry.yarnpkg.com

taobao: https://registry.npm.taobao.org

用于测试的 package.json:

{ "name": "test1", "version": "0.1.0", "private": true, "dependencies": { "react": "^15.5.4", "react-dom": "^15.5.4", "react-native": "^0.45.1", "react-redux": "^5.0.5", "redux": "^3.6.0" }, "devDependencies": { "babel-core": "^6.25.0", "babel-loader": "^7.0.0", "babel-preset-es2015": "^6.24.1", "babel-preset-react": "^6.24.1", "webpack": "^2.6.1" }}

测试机型:

MacBook Pro (15-inch, 2016)

macOS Sierra 10.12.3

CPU2.9 GHz Intel Core i7

网络(无GFW):

评测结果:

|场景|npm5|npm5(taobao registry)|yarn|yarn(taobao registry)|

|---------|---------|---------|

|首次安装|45.856s|40.442s|33.26s|40.85s|

|有缓存 有 lockfile|3.527s|2.153s|0.69s|0.57s|

|有缓存 无 lockfile|2.79s|2.405s|10.04s|15.59s|

|无缓存 有 lockfile|2.465s|2.179s|0.58s|0.56s|

|无缓存 无 lockfile|2.785s|2.511s|27.10s|37.86s|

|有缓存 有 lockfile 删掉 node_modules|24.824s|16.228s|14.31s|14.11s|

|有缓存 无 lockfile 删掉 node_modules|44.764s|30.035s|25.41s|27.91s|

|无缓存 有 lockfile 删掉 node_modules|28.479s|32.827s|25.54s|29.80s|

通过对比可以看出,yarn 的速度在大部分正常场景下还是略高一筹,不过相比之下 npm5 的差距已经很小。

单从数据来看最佳的搭配组合竟然为 yarn 和官方 registry,甚至更换 taobao registry 之后速度反而有所下降,目前还不知道 yarn 是否在自己的源上也有做了特殊优化。

注:单机测试样本不足,也可能有波动或误差,数据仅供参考,感兴趣的读者也可以用自己的项目和网络测一下。

详细测试过程可以查看视频:

视频内容

视频内容

总结

通过以上一系列对比,我们可以看到 npm5 在速度和使用上确实有了很大提升,值得尝试。但从速度上来说 yarn 貌似还是更快一点,也没有足够的理由停止使用 yarn。

综上我个人的建议是如果你已经在个人项目上使用 yarn,并且没有遇到更多问题,目前完全可以继续使用。但如果有兼容 npm 的场景,或者身处在使用 npm,cnpm,tnpm 的团队,以及还没有切到 yarn 的项目,那现在就可以试一试 npm5 了。(另外如果对稳定性要求比较高,鉴于现在才刚发布不久,也可以先了解一下当前的 BUG List 进行衡量)。

以上内容均为原创,如有缪误请指出!

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180118A07Z1Y00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券