令人崩溃的 Node.js 工具生态

起因

需要对一个开源项目进行二开，然后噩梦从git clone之后就开始了。

corepack

Corepack是一个零运行时依赖的Node.js脚本，用作Node.js项目与其开发过程中所需的软件包管理器之间的桥梁。从实际角度来看，Corepack允许您在不安装Yarn、npm和pnpm的情况下使用它们。

其他的就不过多介绍了，这个蠢货东西每次运行的时候都不知道发什么鬼请求，在国内环境下，每次运行都会卡住一会，甚至长达几分钟。

解决方法：

挂上梯子
环境变量：COREPACK_ENABLE_NETWORK设为0

node-gyp

这个就不过多吐槽了，懂的都懂，开发个js项目，居然还需要C++环境编译东西，都不知道学的谁家的好本领，关键是很多项目都没写清楚怎么安装所需要的C++环境，实在受不了，装个VS，里面所有C++环境全勾了，好几十G，慢慢装个够吧。

This version of pnpm requires at least Node.js vXXX

真正的噩梦从pnpm dev开始，一运行直接给我报了个这错误，当时我百思不得其解，我的Node.js环境明明满足版本要求的，关键是他提示出来的版本号，我压根没装这个版本啊，更奇葩的是他最后打印出来的版本号也是没问题的啊！！！这个牛头不搭马嘴的报错是怎么回事，这个v12版本的Node.js环境又是从哪冒出来的，难不成见鬼了嘛。

> mediago@0.1.0 dev O:\Projects\mediago
> tsx scripts/dev.ts && pnpm --parallel -F "./packages/*" run dev
开始构建 development ...
当前所在的目录是: O:\Projects\mediago
$ npm run types
> mediago@0.1.0 types /mnt/o/Projects/mediago
> pnpm -F main run types
ERROR: This version of pnpm requires at least Node.js v18.12
The current version of Node.js is v12.22.6
Visit https://r.pnpm.io/comp to see the list of past pnpm versions with respective Node.js version support.
/// 省略一大堆报错堆栈信息
Node.js v18.12.0
 ELIFECYCLE  Command failed with exit code 1.

然后我去pnpm官方仓库找issue，看下有没有类似的问题，还真找到了好几个，其中都提到了升级pnpm或者使用@pnpm/exe这个包解决。

Cannot find module ‘fs/promises’

于是乎我就使用以下命令尝试升级pnpm

corepack prepare pnpm@latest

升级后再次运行pnpm dev，嘿，好家伙，报错变了，变成了

Cannot find module 'fs/promises'

于是乎又上网一通乱搜，说的是这种写法只有在较新版本的Node.js中才支持，关键是我v18是足够新的啊，我其他项目也是有引用过fs/promises这个包的，所以非常确定是没问题的。

This: not found

实在无奈，只能试试@pnpm/exe这个包了，这个包是独立版本的pnpm，不依赖任何外部Node.js环境，其自身捆绑打包了一个环境。这个工具也是天才设计，运行所有pnpm命令都会新开一个命令行窗口，而且运行完后会立马关闭，甚至pnpm -v都是一闪而过的，想着不想管了，凑合着先用着吧，先把项目跑起来再说，再次pnpm dev，一闪而过一长串的东西，不用问了，肯定又有报错了，因为这个命令行窗口是秒关的，为了截取到报错信息，也是费了九牛二虎之力，终于拿到了，嘿，你猜怎么着，报错又变了，这还是我写了这么多年js以来，第一回看到的报错信息，但这回这个报错不想研究了，赶紧把@pnpm/exe卸载了，纯当不认识这个包。

This: not found

怒删环境

整个晚上整了我这么几回，差点脑溢血，当时就怒删了全部的Node.js环境，pnpm、yarn，各种相关的乱七八糟的全删了，然后去官网整了个v20的重新装了回来，然后用npm把pnpm也装了回来，再次运行，差点气晕过去，又回到了This version of pnpm requires at least Node.js vXXX的报错，我的天！！！

发现线索

实在没有办法了，开始研究这条命令，发现其实是用tsx运行了一个ts脚本，而ts脚本又套娃运行了三条npm命令，真的服了，于是乎我就把这三条命令逐条粘贴到终端运行，居然全都是可以跑通的！然后就重点研究这个ts脚本，发现除了运行那三条npm命令之外，就引用了zx这个库而已，然后又在zx的issue区逛了一下，大概发现了点东西，其中有些issue提到了wsl，当然也没去细看issue内容，随便逛了一下而已，经过这么一提，我就进wsl里面运行了一下node -v，我嘞个豆，出来的版本号就是第一次报错提示的v12.22.6，这应该是Ubuntu系统自带的Node.js环境，所以比较旧。

问题解决

心好累，不想再研究为啥zx会默认跑到wsl里面运行了，简单去研究了一下zx的玩法，添加以下配置到ts脚本就解决了，好累，睡觉了，再多回想一秒我都会原地爆炸的。

if (process.platform === 'win32') {
    $.prefix = '';
    $.shell = 'pwsh.exe';
}

其实这里回看第一次出现的报错，其中的日志也是有线索的，前面的输出路径是Windows格式的，后面那三条命令输出的路径已经变成了Linux格式的，当时没发现这个细节。

刚开始: O:\Projects\mediago
后面的：/mnt/o/Projects/mediago

最后再提一嘴，环境能隔离一定要隔离，别嫌麻烦，装一起用起来固然爽，等出现交叉问题的时候，总能以你这辈子都想象不到的方式出现在你面前。