Travis CI 上的一个校验问题

  在一个多月前发现draft-js-plugins/nextTravis CI 老是失败;那时候看了下日志,发现是flow 的脚本报找不到模块的错误了。但是,奇怪的是在本地怎么也重现不了。后面,项目的主要维护者也没发现哪有问题,于是就暂时去掉Travis CI 上的flow 脚本。

  直到今天,我花了不少的时间查那个找不到模块的错误;经过不少的试错,最后发现是安装依赖的时候有问题导致的。项目在Travis CI 上使用的是lerna bootstrap --hoist 在安装各个包中声明的依赖的。关于这个hoist参数,在lerna 的官方文档中有专门的说明。在使用lerna 管理多个独立包的时候,各个包之间难免会存在有重复依赖的情况;重复的依赖就以为着会重复安装,也会占用不必要的空间。而hoist 就是为了解决重复安装而存在的;带上hoist 执行lerna bootstrap 的话,各个包之间的重复依赖只会安装到项目的根目录。
nohoist.svg

lerna bootstrap

hoist.svg

lerna bootstrap --hoist

  在lerna 的hoist 文档有特别说明hoist 的弊端。一大弊端就是有可能有解析问题:大致的意思是,Node 模块的解析是一个递归的过程,如果在当前目录没找到「没有node_modules 文件夹,或者有node_modules 文件夹但没在里面找到」;就会往上层目录找,直到找到或者去到根目录为止。上述的解析过程并不是一个标准的规范;所以一些没有遵循该解析过程的工具一旦遇到hoist就会出现Can not resolve xxx module 的错误了。

  嗯,flow 就没有遵循递归往上查找的方法;它只在本目录去找,找着了就找着;没找着就没找着了>_<。也许是考虑到这些没有遵循递归往上查找模块的工具,lerna 还提供了一个nohoist 的配置让你指定某些依赖不进行hoist 处理。下面的示例配置就是不对packages 或examples 下的draft-js依赖进行hoist 处理。

{
  "packages": [
    "examples/*",
    "packages/*"
  ],
  "nohoist": ["**/draft-js"]
}

hoist with nohoist.svg

  后记,lerna 使用hoist 安装依赖,除了会引起上面说的模块解析弊端之外;还有一个不太起眼的弊端,hoist 是对有重复的依赖进行处理。这样会造成,某些package 没有在package.json 中声明已经被hoist 的依赖仍然能顺利的打包之类的。一旦,这个package 脱离了这个monorepo;就会出现解析模块失败的问题。当然啦,也不用太担心这个弊端,使用这个eslint-plugin-importno-extraneous-dependencies 规则,就能够规避这个问题了。

您的浏览器已过时

要正常浏览本网站请升级您的浏览器。现在升级

×