npm install 任务启动时间过长答案

【问题标题】：npm install task taking too long to startnpm install 任务启动时间过长
【发布时间】：2018-01-15 10:21:21
【问题描述】：

TFS 2017 构建定义上的 npm 安装任务在 Ubuntu 构建代理上启动时间过长：

2018-01-12T08:09:05.2269721Z [command]/usr/bin/npm install
2018-01-12T08:11:39.9810116Z npm WARN prefer global node-gyp@3.6.2 should be installed with -g
2018-01-12T08:11:43.0553293Z 
2018-01-12T08:11:43.0578286Z > node-sass@4.7.2 install /home/johnny/myagent/_work/9/s/node_modules/node-sass
2018-01-12T08:11:43.0601546Z > node scripts/install.js

我想知道是什么导致 npm 需要 3 分钟才能启动。如图所示，它从 08:09:05 开始，第一次回调是在 3 分钟后 08 :11:39

【问题讨论】：

尝试npm install --verbose（提供更详细的输出），检查输出是否有任何问题。如果需要进一步的帮助，请将详细输出粘贴到问题中。
构建任务是否成功完成？如果在 TFS 构建管道中使用其他 npm 命令，你会得到相同的行为吗？

标签： node.js ubuntu npm tfs tfsbuild

【解决方案1】：

如果这种行为只发生在NPM install 命令上，这是有道理的。 NPM 安装只是在浪费时间，因为它需要 3-4 分钟来确定软件包是否已安装。

尝试从控制台运行 npm 以查看 TFS 上的性能是否正常。如果您所有的 NPM 任务都需要很长时间，则一种可能性与 nodejs 版本有关。

例如，您使用的是安装在构建代理上的最新版本，例如 nodejs (8.x.0)。然后降级到最新的 LTS（长期支持）版本 (6.11.1) 可能会为您解决问题。详情请看这个blog。

如果您没有执行构建代理清理，另一种方法是通过缓存以前安装的依赖项在构建机器上使用npm-cache。

对于运行 [npm|bower|composer|jspm] 的构建进程很有用每次安装作为其构建过程的一部分。由于依赖不要经常更改，这通常意味着构建时间较慢。 npm 缓存通过缓存以前安装的缓存来帮助缓解这个问题依赖于构建机器。 npm-cache 可以是一个插件替换任何运行 [npm|bower|composer|jspm] 的构建脚本安装。

工作原理

当你运行 npm-cache install [npm|bower|jspm|composer] 时，它首先在当前目录中查找 package.json、bower.json 或 composer.json 工作目录取决于请求的依赖管理器。然后它计算配置文件的 MD5 哈希值并查找对于缓存目录中名为 .tar.gz 的文件（$HOME/.package_cache 默认）。如果文件不存在，npm-cache 使用系统的安装依赖管理器来安装依赖。一旦安装了依赖项，npm-cache 将新下载的 tars 依赖项并将它们存储在缓存目录中。下一次 npm-cache 运行并看到相同的配置文件，它会找到 tarball 在缓存目录中解压当前目录下的依赖工作目录。

供您参考的样本：Speed up your npm dependent CI build

【讨论】：