记录一个node execSync执行时间很久的问题

这个问题发生在不知道什么时候发现一个项目的webpack打包时间变得很久，在进入打包逻辑之前停顿了几分钟的样子；

一直以为是项目依赖多了或者某个组件导致的,慢就等会，有空再分析原因；

昨天就花了些时间分析了一下，打包过程时间分布;

参考下面几个帖子:

https://juejin.im/post/6844904056985485320

https://segmentfault.com/a/1190000018493260

https://segmentfault.com/a/1190000008377195

通过speed-measure-webpack-plugin插件我们可以看到打包过程中的各个过程的时间占用,但是发现似乎不包含我们上面的那个时间;

进一步分析后发现是构建之前的require('./check-versions')()导致的,进一步的定位到

require('child_process').execSync(cmd).toString().trim()

当cmd为npm --version时就会出现长长的阻塞等待，实际上在命令行这个命令执行要不了多久;

 现象和这个仁兄描述的是一致的https://segmentfault.com/q/1010000011707690/a-1020000011711975

当cmd改成node --version则不会出现这个运行很久的现象,当传入选项为stdio:'inherit'时,也能够很快跑下去,但是这个时候输出到了父标准输出,

无法使用toString获取结果;

同样的传入参数改为文件句柄,运行也很快;

var out = fs.openSync('./out.log', 'a');

。。。stdio:['inherit',out,'inherit']

var data = fs.readFileSync('./out.log')

------------------------

很明显的stdio:'pipe' 时就会发生运行很久的问题,换成另外的win10机器现象有所好转,但是还是挺久的;

 切换node版本问题依旧;

翻了翻：

https://github.com/nodejs/node/blob/master/lib/internal/child_process.js

https://github.com/nodejs/node/blob/master/src/spawn_sync.cc

感觉问题可能在win10的管道上,execSync还是尽量别用了;

---------------------------

进一步分析:

node --version的调用其实是node.exe --version

npm --version在windows上调用的是npm.cmd脚本

==>我们将最终的命令打印出来"%NODE_EXE%" "%NPM_CLI_JS%" %* =>echo "%NODE_EXE%" "%NPM_CLI_JS%" %*

形如:

'"C:\\Users\\xxxx\\node-v13.6.0-win-x64\\node.exe" "C:\\Users\\xxxx\\node-v13.6.0-win-x64\\node_modules\\npm\\bin\\npm-cli.js" --version'

替换后运行也很快就结束了,意味着问题出在当我们调用的目标是一个bat脚本的时候;

参考:

child_process fork ipc

https://gist.github.com/ndelangen/3b2b981a4795e51ef4f8cf583764eb8a

https://theantway.com/2016/12/capture-console-output-when-using-child_process-execsync-in-node-js/

https://html.developreference.com/article/16877584/Why+NodeJS+execSync()+is+too+slow+when+executing+custom+scripts