ESLint 校验规则集的思考

最近想着把 TSLint 切成 ESLint,所以也就看了一下我们之前的 ESLint 的方案,以及对代码检测的方案以及流程,对于我们团队目前的现状来说,开发场景涉及到 Web、Node、RN 等技术场景,未来还有可能会涉及到小程序等方面,以及 TS、JS、React 等,而这些都是属于不同的校验规则集,而且有最要命的情况是 review 不到位的情况下,并且会跑出来很多的 eslint-disabled、ts-ignore 等。

如何解决

基于 ESLint 的插件化以及可继承覆盖的特性,就可以层层递进,面向多场景、多技术的配置方案,同时我们因为是只提供了配置文件,不是去封装东西,所以它能够做到很好的扩展性,同时能更好的进行维护。

所以方案是,提供 ESLint 的配置集,供各种场景使用。

如:

  • 基于 Airbnb 或者是其他的规则集,配置属于我们风格的基础规则集
  1. 基于我们刚刚提供的基础规则,向上扩展出 React、RN、Node 等规则集
  2. 同时在上一层的配置中,可选的添加 ts 的配置支持
  3. 最后再根据各项目的不同情况来继承上述的规则,进行定制化的修改

好处

  1. 易维护,关于基础语法、风格的改动,只需要改动 eslint.base 就能够在所有项目生效
  2. 低耦合,各个上层配置或者框架层级之间无耦合性
  3. 易扩展,后续有什么其余框架、或其他类型技术选型的 lint,方案也可以基于我们原有的上层配置进行扩展

代码集成检查

在我们现在的开发流程中,有以下两种方式进行代码检查。

  1. pre-commit: 借助于 husky、lint-staged 触发 ESLint 检查,优点很明显,反馈很及时,不需要在线上跑 CI 的时候再报错,这周期就太长了,并且无法保证所有开发都不会悄悄地 --no-verify
  2. CI: 这一步应该是在提交 mr 之后,进行 ESLint 检查,如果检测不通过就停止交付,当然了,优点是强制执行,通过 Sonar 等检测工具,还可以生成检测报告,这一步我想可以放在我们的研发流程平台上
Last Updated: 8/19/2019, 3:59:54 PM