从一次 yarn 命令死循环说起

前言

最近有个想法，希望在一个 yarn workspace 项目中实现任意一个子包中安装依赖时，都执行一些类似于初始化、同步配置的动作。

然而在操作过程中遇到了一个关于 yarn --cwd 有趣的问题，特地记录下来，希望能对后来者有所帮助。

遇到什么问题呢

先交代一下我们项目的基本情况，它是一个通过 yarn workspace 管理的 monorepo 项目，使用的是 yarn v1.22.11 版本，目录结构大致如下：

monorepo
├── package.json
├── app-a
│   └── package.json
├── app-b
│   └── package.json
└── config
    └── package.json

其中 app-a 和 app-b 都使用了 config 这个共享包：

"dependencies": {
  "@monorepo/config": "../config",
}

我们需要在根目录的 package.json 中的 preinstall 钩子做一些初始化操作：

"scripts": {
  "preinstall": "./bin/init.sh",
}

此时我们在根目录执行 yarn 或者 yarn add <pkg-name>，都会触发 preinstall 这个钩子，但在 app-a 中执行 yarn是不会触发根目录的 preinstall 钩子的。

因此，我们需要分别在每个子包上都加上这行，也即在每个子包安装依赖时都执行一下根目录的 preinstall 命令：

"scripts": {
  "preinstall": "yarn --cwd ../ preinstall",
}

于是，奇怪的事情就发生了，当我在 app-a 中执行 yarn 的时候，它停留在安装 @monorepo/config 的阶段，同时我的电脑明显变得卡顿，于是打开 htop 一看，好家伙，满屏都是：

4ark   40987  26.3  0.5 409250368  78624   ??  R  8:36下午   0:00.09 /usr/local/bin/node /usr/local/bin/yarn --cwd ../ preinstall

CPU 占用率直接达到 100%，吓得我赶紧 kill 掉这些进程：

ps aux | grep preinstall | awk '{print $2}' | xargs kill -9

分析原因

惊吓过后，来分析一下原因，很显然这段命令陷入了死循环，导致越来越多进程，于是尝试在每个子包中都手动执行一遍 yarn --cwd ../ preinstall 后，发现一切正常，那问题出在哪呢？

于是我再执行了一遍 yarn，并且用以下命令将进程信息复制出来，以便分析：

ps -ef | pbcopy

随后验证我刚刚的猜测，的确是这个命令在不断触发自己，导致死循环：

UID   PID  PPID   C STIME   TTY     TIME CMD
501 50399 50379   0  8:50下午 ??   0:00.10 /usr/local/bin/node /usr/local/bin/yarn --cwd ../ preinstall
501 50400 50399   0  8:50下午 ??   0:00.11 /usr/local/bin/node /usr/local/bin/yarn --cwd ../ preinstall
501 50401 50400   0  8:50下午 ??   0:00.11 /usr/local/bin/node /usr/local/bin/yarn --cwd ../ preinstall
501 50402 50401   0  8:50下午 ??   0:00.12 /usr/local/bin/node /usr/local/bin/yarn --cwd ../ preinstall

由于三个分包执行的命令都一样，不清楚是不是由于某个分包引起，于是修改一下命令以便区分：

"scripts": {
  "preinstall": "echo app-a && yarn --cwd ../ preinstall",
}

随后发现问题是出现在 config 这个子包，于是我把这个子包的 preinstall 命令去掉，果然没有这个问题了，非常奇怪。

难道是 --cwd ../ 这个路径有问题？验证一下，把命令改成这样：

"scripts": {
  "preinstall": "pwd && yarn --cwd ../ preinstall",
}

发现 pwd 输出是这样子的：

/4ark/projects/monorepo/app-a/node_modules/@monorepo/config

从这里的输出我们发现了两个问题，第一个问题是：

yarn workspace 共享包的 preinstall 被执行的时候，其实已经被拷贝到 app-a 的 node_modules 中，而不是在当前目录，因此 --cwd ../ 并不指向项目根目录。

这一点比较好理解，毕竟 config 作为一个依赖包，确实应该被拷贝到应用的 node_modules 。

而第二个问题就不太理解了，为什么明明设置了 --cwd ../，却依然在当前目录执行呢？按照预期 cwd 的指向应该是：

/4ark/projects/monorepo/app-a/node_modules/@monorepo

难道是我对 cwd 参数的理解有偏差？看一下 yarn 的文档中对 cwd 描述：

Specifies a current working directory, instead of the default ./. Use this flag to perform an operation in a working directory that is not the current one.

This can make scripts nicer by avoiding the need to cd into a folder and then cd back out.

从文档的描述来看，cwd 的作用不就是代替 cd 吗，但现在的结果看来 yarn --cwd ../ preinstall 并不等价于 cd ../ && yarn preinstall 。

这就不得不让人疑惑 cwd 的定位方式了，在网上搜寻一番没找到相关的讨论，那只能自己动手丰衣足食，直接从 yarn 源码中寻找答案。

分析源码

前面我们说到，我们使用的是 yarn v1.22.11，在 yarn 的 GitHub 仓库中发现 v1 版本的最新版本停留在 v1.23.0-0，那我们就从这个版本的源码来进行分析，首先克隆代码到本地：

git clone --depth=1 https://github.com/yarnpkg/yarn

然后安装依赖并运行起来：

yarn && yarn watch

这时候它就会自动监听代码修改然后重新编译，我们查看 package.json 发现 yarn 的 bin 主要是调用 ./bin/yarn.js:

"bin": {
  "yarn": "./bin/yarn.js",
  "yarnpkg": "./bin/yarn.js"
},

也就是我们直接执行 bin/yarn.js 的效果就如同执行 yarn，试一下查看版本：

> /Users/4ark/projects/yarn/bin/yarn -v
1.23.0-0

PS：当然你也可以在项目目录下使用 npm link 把它挂载到本地中。

接下就是一番调试，终于定位到可以回答我们疑问的代码，在这里：

function findProjectRoot(base: string): string {
  let prev = null;
  let dir = base;

  do {
    if (fs.existsSync(path.join(dir, constants.NODE_PACKAGE_JSON))) {
      return dir;
    }

    prev = dir;
    dir = path.dirname(dir);
  } while (dir !== prev);

  return base;
}

const cwd = command.shouldRunInCurrentCwd ? commander.cwd : findProjectRoot(commander.cwd);

可以看到 cwd 的定位方式是从当前目录寻找是否存在 package.json，若存在，则返回此目录，否则将目录经过 path.dirname 处理一遍，继续寻找，直到寻找到最外层。

那么这里最关键的是 path.dirname 的返回值，我们先看一下文档对于它的描述：

The path.dirname() method returns the directory name of a path, similar to the Unix dirname command. Trailing directory separators are ignored,

就是返回一个路径中的目录部分，作用与 unix 下的 dirname 命令一致，通常是这么使用的：

> dirname /4ark/app/index.js
/4ark/app

> dirname /4ark/app/packages/index.js
/4ark/app/packages

是不是会肤浅地认为它的作用就是返回一个路径的上一级目录？如果传入的是一个绝对路径，确实可以这么肤浅地认为，然而当传入的是一个相对路径时，情况就不一样了：

> dirname ../app/index.js
../app

> dirname ../../
../

> dirname ../
问: 会返回什么呢？

答案是：.，也就是当前目录。

那这里就能回答我们之前的问题，为什么在 node_module/@monorepo/config 中使用 yarn --cwd ../ preinstall 却在当前目录执行，因为它的上一级 node_modules/@monorepo 不存在 package.json，所以经过 dirname ../ 处理后 cwd 的指向就是当前目录。

如果对 node.js 中 path.dirname 的实现方式感兴趣，可以看这里 path.js#L538-L554。

解决方案

摸清楚原因后，那解决这个问题也不是难事，只要我们把相对路径改成绝对路径，是不是就能解决这个问题了？

思考一下，其实 yarn --cwd ../ preinstall，把 ../ 改成绝对路径行不行呢？比如在本文的场景，../ 其实就是项目的根目录，那我们完全可以通过别的方式获取到项目的根目录，比如在 git 中：

git rev-parse --show-toplevel

所以，我们把命令改成这样，问题就迎刃而解了：

- yarn --cwd ../ preinstall
+ yarn --cwd $(git rev-parse --show-toplevel) preinstall

那就不得不提一下，其实在 yarn v2 中新增了一个 --top-level 属性，它的作用刚好就是为了解决这个问题。

结语

其实我们再回过头来想，在本文的例子中，根本不需要在 config 目录中添加 preinstall 这个钩子，因为它作为共享包，每次修改都必然要在其它使用这个包的地方，重新安装一次，所以只要确保这些地方会执行 preinstall 就可以了，那也就意味着不会出现本文遇到的问题。

不过，多踩坑也不是坏事，只要搞清楚背后的原因，问题也就不是问题。