[email protected] 依赖一个特定版本的 boost 库

[email protected] 依赖的是 facebook 精简之后的 boost_1_63_0 版本，而不是官方在 sourceforge 上发布的那个版本。

官方发布的版本是这样的。

curl -Lo boost_1_63_0.tar.gz \
   https://sourceforge.net/projects/boost/files/boost/1.63.0/boost_1_63_0.tar.gz

shasum -a1 boost_1_63_0.tar.gz   # macOS, = 2cecf1848a813de55e5770f324f084c568abca0a
sha1sum boost_1_63_00.tar.gz     # Linux, = 2cecf1848a813de55e5770f324f084c568abca0a

而 Facebook 自己改过的版本是这样的。

curl -Lo boost_1_63_0.tar.gz \
    https://github.com/react-native-community/boost-for-react-native/releases/download/v1.63.0-0/boost_1_63_0.tar.gz

shasum -a1 boost_1_63_0.tar.gz   # macOS, = c3f57e1d22a995e608983effbb752b54b6eab741
sha1sum boost_1_63_00.tar.gz     # Linux, = c3f57e1d22a995e608983effbb752b54b6eab741

这是个比较大的坑。

依赖第三方开源 lib，文件名与第三方官方 release 的文件名一致，内容却是自己修改过的。稍不注意就会上当。

因为之前有习惯先通过别的途径下载这个大文件，手动放置到 ~/.rncache 缓存目录下，所以发现了这个问题。

---

补充说明，为什么说这是一个坑。

react-native run-ios

在模拟器上运行 ios 版本的时候，脚本会首先编译 ios 版本的 app 出来。从安装脚本 node_modules/react-native/scripts/ios-install-third-party.sh
文件最后部分可以看到，会下载编译 ios 版本所需要的几个第三方库并编译。其中就包括了 boost_1_63_0.tar.gz 这个第三方库。

在一个多月前，大约 [email protected]
版本的时候，facebook 还是依赖的官版 boost_1_63_0，可能是发现某些国家的码农反映比较强烈，因此转成依赖自己精简过后的 boost_1_63_0。官版的 boost_1_63_0.tar.gz 文件有 93MB 之大，某些国家的码农无论访问 sourceforge（boost 官版的发版平台）还是 github 都很慢，几乎所有要在新环境运行项目（包括想要尝鲜）的码农们都遇到过下载这个大文件失败的情况。一个第三方依赖库下载失败，错误信息常常隐藏在大段大段的日志中，尝鲜的人容易漏掉，并且造成一种『ReactNative 不成熟，「Hello World」都不容易跑起来』的第一印象。有经验的码农们能发现这个问题，也不容易解决。即便有能力找到快速的源预先下载好依赖，自动化构建的过程被破坏了，也是一种非常糟糕的体验，对一个开源的框架来说，不能容忍。

所以，从前段时间开始，大约是 [email protected]
，Facebook 开始使用一个精简版的 boost 库。就像 google 自己的 boringssl
库 一样，facebook 以社区的名义为了这事儿维护了一个自己的版本。好在，目前来看，仅仅是一个精简官版的工作，还不涉及到修改。

出发点是一个好事儿，但是这么一来，增加了项目管理和维护风险。起步的小伙伴们，要小心一点。