前段时间 npm 发布了 5.0 版本,提供了自动记录依赖树,下载使用强校验,重写缓存系统等功能升级和改造,吸引了不少关注。本文将对 npm5 的新功能和变化点在进行实践使用后进行介绍和总结,并和 yarn 进行简单对比。
通过官方的 Release note 我们可以看到 npm5 的主要新功能和大改动主要有下面几点(后面将会详细介绍):
除此之外还包含一些细节优化:
下面就来对主要的修改点做详细介绍和对比:
本次 npm5 新增了 package-lock.json 文件,在操作依赖时默认生成,用于记录和锁定依赖树的信息。使用过 yarn 的同学应该能感觉到,这次 npm5 的很多改动都有参考 yarn,这里估计也是在 yarn 的 lockfile 大受欢迎的背景下做出了这个修改(其实之前的 npm 版本并不是没有 lockfile,后面会提到)。
在首次执行 npm install 后,会默认创建 package-lock.json 文件。
之后再次 install 将根据此文件中的记录进行安装。
如果对依赖进行了修改(新增依赖、npm update 或 npm install 指定不同版本的包),都将更新记录到此文件中。
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 在使用场景上也有以下不同点:
具体规范文档可以参考:
关于 npm-shrinkwrap.json 文件,还要注意之前的版本是不包括 devDependencies 的,而这次升级 npm5 后 devDependencies 将被包括进来。所以如果使用旧版时已有 npm-shrinkwrap.json 文件,这次升级后再次 install 时会把这些缺少的依赖加进去(npm5 之后会通过 "lockfileVersion" 字段来判断 shrinkwrap 的版本)。因此多人开发时要注意大家同步升级,避免产生新旧混用的情况。
综上我们能总结出 package-lock.json 和 npm-shrinkwrap.json 在项目中的适用场景:
我们已经知道,生成 package-lock.json 后,重复执行 npm install 时将会以其记录的版本来安装。这时如果手动修改 package.json 中的版本,重新安装也不会生效,只能手动执行 npm install 命令指定依赖版本来进行修改。
而这一点 yarn 是可以做到的。猜想 yarn 在执行前是先对比了一遍 package.json 和 yarn.lock 中的版本,如果版本范围完全不符的话会重新安装并更新 lockfile。
在 npm5 中,配置的 registry 优先级要高于 lockfile 内记录的 registry 的优先级。如果设置的 registry 和 lockfile 中的不同,将使用设置的 registry 安装(命中缓存时除外)。
这一点也和 yarn 不同。yarn 在有 lockfile 时会完全忽略 config 中的 registry。个人感觉 npm5 的设定更加合理,否则有频繁切换 registry 需求的用户可能会比较难受。
新版本对 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
使用文件安装依赖这个功能仅有 npm 支持,目前 yarn 还不支持(截至 yarn@0.24.6)。
有关新的 file:// 规范描述可以参考官方的 file-specifiers。
具体修改和实现可以参考这个 PR。
新版本重写了整个缓存系统,缓存将由 npm 来全局维护不用用户操心,这点也是在向 yarn 看齐。升级新版后,用户基本没有手动操作 npm cache 的场景。npm cache clean 将必须带上 --force 参数才能执行,并且会收到警告:
--cache-min --cache-max 也已废除。同时在离线安装等场景将会提高缓存使用的优先级,提升安装速度。
这里使用目前最新的 npm@5.0.3 版本,和 yarn@0.24.6 版本,分别在使用各自的官方 registry 和 taobao registry 的情况下进行以下几种场景的速度对比:
registry:
用于测试的 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 进行衡量)。
以上内容均为原创,如有缪误请指出!
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。