这是一条被编辑掉的评论。

为什么有一些人轻而易举就理解了，有一些人则一直卡住呢？

通过阅读 yarn 的源码，发现这一步就是执行了各个安装了的包裹里的 postinstall 而已…… 而卡住的罪魁祸首是 node-sass 这个包。它默认会去 GitHub 的 release 上下 binary，而 GitHub 的 release 放在 S3 上，国内很多地方访问不畅。gist 上有方法修改它的下载地址为淘宝的镜像，但是现在似乎不太管用了。于是我阅读了它的源码： function getBinaryUrl() { var site = getArgument('--sass-binary-site') || process.env.SASS_BINARY_SITE || process.env.npm_config_sass_binary_site || (pkg.nodeSassConfig && pkg.nodeSassConfig.binarySite) || 'https://github.com/sass/node-sass/releases/download';

const result = [site, 'v' + pkg.version, getBinaryName()].join('/');

return result; 在我这里设置 yarn 配置似乎不管用，所以我干脆就设置环境变量 SASS_BINARY_SITE 了……确实非常管用，立马不卡。

关于帖子主干中提到的问题，为什么 serve-static 并不是一个 @types 下的包，却依然发生了错误？ 这是因为它有一个 @types/serve-static 的对应包，并且 yarn.lock 里 serve-static 的 integrity 被写成了 @types/serve-static 的，这样你怎么装都装不对了。

现在还有两个疑点没解决： 没有 integrity 字段到底碍不碍事？ 为啥读取 yarn 离线缓存报错之后停止安装了，但还是会发网络请求？

那么它究竟是从哪里搞到这个 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 ? {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，前途未卜。

这次终于彻彻底底搞明白原因了，我之前说的可能并不正确。当然现在这个新的理论似乎也无法解释前面 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 的内容的呢？ 好了，高潮就要来了，咱们先歇会儿……

这次还真遇到一个库因为没开这个选项导致使用失败的案例：fix(tsconfig): Allow default style import in the commonjs version build. 不过这个 pull request 似乎我也没完全搞定……

经过叶子哥哥的提醒，发现是因为 GNOME 的 SOCKS5 代理仅仅是设置了一个环境变量而已……而 root 的环境变量并无法受到 GNOME 的影响，所以其实这个代理就是坏的，root 是因为没有设置代理所以是好的……

这么写的： admin = Observable.create((observer) => { let value = true; observer.next(value);

this.toggleAdmin = () => { value = !value; console.log('changing to ', value) observer.next(value); } });