我终于找到 CI fail 的原因了！

它之前给我的错误提示是：

$ yarn
yarn install v1.12.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error http://registry.npm.taobao.org/serve-static/download/serve-static-1.13.2.tgz: Integrity check failed for "serve-static" (computed integrity doesn't match our records, got "sha1-9axNemQgqZpqRa9HGfTc2M2Qekg=")
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Reply

Colliot12/1/2018, 2:30:25 PM

这次终于彻彻底底搞明白原因了，我之前说的可能并不正确。当然现在这个新的理论似乎也无法解释前面 serve-static 包失败的原因——也许那还有待调查……

这次我发现一些 @types scope 下的包频繁出现安装失败，以及另一种更有意思的现象——被装成了不带 @types 的那个包，比如 @types/prop-types 被装成了 prop-types。这会导致 TypeScript 编译的时候频繁报告一些奇怪的错误，比如 TypeScript error: Cannot find type definition file for 'prop-types'. TS2688，TypeScript error: Cannot find type definition file for 'retry'. TS2688，以及在净土本身的项目里似乎遇到过 TypeScript error: Cannot find type definition file for 'express'. TS2688，这个最后我发现也是因为@types/express 被装成了 `express。

前几天我忍无可忍，去调试了 yarn 的源码，发现 yarn 第二步去 fetch 包的步骤是这样的：

试图在 yarn 的缓存目录（macOS 下是 ~/Library/Caches/Yarn/v4/）里寻找缓存，比如 @types/prop-types 的缓存可能叫 `~/Library/Caches/Yarn/v4/npm-@types-prop-types-15.7.2-0e58ae66773d7fd7c372a493aff740878ec9ceaa/`。
如果这个缓存存在，那就使用这个缓存。如果启用了 yarn-offline-mirror，那么就把这个缓存移动到 offline mirror 里。（实际上这个缓存目录里的 node_modules/@types/prop-types 文件夹里除了存在包展开后的内容，还有一个压缩包 .yarn-tarball.tgz，它是直接拷贝过去的。
如果没有缓存，那就试图走离线缓存，即检查指定的 yarn-offline-mirror 目录里是否存在对应的压缩包。如果有，就用它。
如果啥都没有，那只能从网络上获取了，就是走指定的 npm/yarn 源下载咯。

在调试过程中，我还发现一些奇怪的现象，最终通过这些现象彻底搞清楚了问题在哪里（其实修法很简单，但真的是画一条线只值一美元，知道在哪里值 999999 美元……）。这些奇怪的现象有：

如果不用淘宝 npm 源，而用 npm 官方源或者 yarn 官方源，并把 yarn 缓存、yarn.lcok 和离线缓存清掉重装，就没有问题。
yarn.lock 里的 integrity 字段竟然是不带 @types 那个包的
把 yarn.lock 里带 @types 那个包的内容删掉（或者干脆整个文件都删掉）再装，不会出现 Integrity check failed，但是装上去的包还是错的
yarn 缓存里的包就是错的…… ~/Library/Caches/Yarn/v4/npm-@types-prop-types-15.7.2-0e58ae66773d7fd7c372a493aff740878ec9ceaa/ 里的包竟然是 prop-types-15.7.2，而不是 `@types-prop-types-15.7.2`
删掉 yarn 缓存里的这条缓存之后再装，这个缓存竟然又变成了 prop-types……
把发网络请求那一段打出来，发现发的网络请求是对的。保存了网络请求的结果，发现结果也是对的（shasum 结果跟正确的压缩包相同）。那么 yarn 到底是从哪里搞到这个错误的包的内容的呢？yarn 试图装 prop-types 的时候，是从哪里搞到这个 prop-types 的内容的呢？

好了，高潮就要来了，咱们先歇会儿……

Reply

Colliot9/9/2019, 3:45:38 PM

那么它究竟是从哪里搞到这个 prop-types 的内容的呢？通过反复执行和调试，我终于发现，它在安装 @types/prop-types 时，竟然是在步骤 3 而不是步骤 4 出错的……也就是说，它的 Integrity check failed 的来源，是步骤 3 那个离线缓存文件……但是我去翻了那个目录，发现并没有这样的文件，这又是为什么呢？

这时候我看了那个文件的名字，终于发现了最后的答案——那个它试图读取的文件的名字，是 prop-types-15.7.2.tgz！！！！！

这个文件为什么会存在呢？是因为步骤 2——当我们先安装 prop-types 时，这个离线缓存会被先创造出来。当我们安装失败后，它又被回滚掉了，所以我们并看不见它。

现在的问题就来到了，为什么 yarn 在安装 @types/prop-types 时，却试图去读取 prop-types-15.7.2.tgz 呢？这已经非常容易了，我们只需要去看代码就行了。这一段代码在这里：

    const match = pathname.match(RE_URL_NAME_MATCH);

    let packageFilename;
    if (match) {
      const [, scope, tarballBasename] = match;
      packageFilename = scope ? ``_mathjax_internal${scope}-$]^$`{tarballBasename}` : tarballBasename;
    } else {
      // fallback to base name
      packageFilename = path.basename(pathname);
    }

我们发现如果正则匹配失败，它就会取包的 basename，也就是没有 scope 的 name。那么为啥它会匹配失败呢？我们来看看这个正则：

const RE_URL_NAME_MATCH = /\/(?:(@[^/]+)(?:\/|%2f))?[^/]+\/(?:-|_attachments)\/(?:@[^/]+\/)?([^/]+)$/;

看起来非常复杂，但我们只要关心这个中缀 \/(?:-|_attachments)\/ 就行了。它是啥呢？npm 源会先返回一个包的 meta info，比如 @types/prop-types 的：https://registry.npmjs.org/@types/prop-types ，里面有每个版本的下载地址，比如 15.7.2 的就是 https://registry.npmjs.org/@types/prop-types/-/prop-types-15.7.2.tgz。这个中缀正则就是为了匹配 URL 里的 /-/ 这段。问题就出在这里——淘宝源 https://registry.npm.taobao.org/@types/prop-types 返回的 URL 是 https://registry.npm.taobao.org/@types/prop-types/download/@types/prop-types-15.7.2.tgz，中缀是 /download/，这显然并无法被匹配，所以就走到了 fallback 的分支，去读取 basename 也就是 prop-types 对应的缓存了……

于是真相大白了。解决方案也很简单，只要给这个中缀正则加上 download 的情形即可。提了一个 pull request，前途未卜。

Reply

Colliot9/9/2019, 4:10:00 PM

现在还有两个疑点没解决：