3.3　使用ESLint规范编程风格

editorconfig只对程序文件的通用基本格式进行了限制，并不关心某个编程语言自身的语法特性，而ESLint可以说是专为JavaScript服务的代码检查工具。ESLint通过对工程目录中的js或jsx文件执行自动扫描来查找常见的语法和代码风格错误（安装插件后即可支持ts和tsx），并根据用户设定的报警等级给出提示，甚至还可以配置自动修复策略。它的整体架构是一个插件平台，这就意味着我们可以只让自己期望的检测规范生效，或者编写自己团队专属的检测规范，而不是被动地接受某些设定。当然，如果你觉得配置很烦琐，也可以直接下载一些知名的前端技术团队开源的配置文件来使用。

另一方面，ESLint的流行得益于其广泛支持的集成方式，我们不仅可以通过编辑器插件使用它，也可以直接在命令行中启用它，或者配合各种自动化构建工具及API通过编写代码的方式将它接入自己的前端工程化体系中。ESLint具有如此广泛的适用性，可以称得上是业界良心了。

3.3.1　配置文件和规则集

ESLint可以支持如下两种配置方式。

  • 注释配置：直接使用JavaScript注释把配置信息嵌入代码源文件中。
  • 文件配置：使用JavaScript、JSON或YAML文件格式为整个目录配置“.eslintrc.*”文件来存放配置信息。

通常建议的策略是使用文件配置的方式来编写配置，而在特定的场合下，使用注释配置的方式可以避开某些检测项目。我们可以在安装ESLint工具后，使用“eslint --init”命令初始化生成一个配置文件，只需要根据向导的提示做一些选择，就能够得到一个eslintrc配置文件。ESLint拥有很多配置项，官方网站上提供了非常详细的使用说明，虽然烦琐但并不复杂，本书就不再赘述了，仅针对其检测规则集配置项rules进行说明，规则集的配置格式如下：

rules:{
    "规则名" : [规则值, 规则配置]
}
//规则值支持:"off"或0表示关闭，"warn"或1表示告警，"error"或2表示错误

下面展示的是一份配置好的“.eslintrc.js”文件（以JavaScript格式为例）：

module.exports = {
    //根级设置，全局生效
    "root":true,
    //设置支持的环境，支持的环境激活后会提供一组特定环境的预定义全局变量
    "env":{
        "browser":true,
        "node":true
    },
    //要检查的规则集
    "rules":{
        // 进行条件判断时，强制使用"==="或"！=="，告警级别为"错误"
        "eqeqeq" : 2,
        // 禁止在条件表达式中出现赋值语句，告警级别为"错误"
        "no-cond-assign" : 2,
        // 禁止使用alert()方法，告警级别为"警告"
        "no-alert" : 1,
        // 禁止使用eval方法，告警级别为"错误"
        "no-eval" : 2
    }
}

把上面的配置文件放在项目的根目录下，通过任何一种方式启用ESLint对代码进行检查，都会得到上述几个规则的检测结果，开发者一般会选择在IDE中安装ESLint插件的方式来使用。官方提供的可选检测规则多达200条，我们可以从中筛选出自己需要的规则，或者下载共享配置文件，然后通过配置文件中的“extends”字段来启用官方推荐的规则，或者使用某些知名的前端团队提供的开源规则集。例如，下面的配置就会默认启用ESLint官方推荐的规则（即官方网站的规则集中所有带有绿色对号标记的规则）：

"extends" : "eslint:recommended"

如果在某些特殊场景中，需要有针对性地避开某些检测规则（而不是对整个工程禁用某项检测），则可以使用下面的语法在源代码中进行注释：

alert('foo'); /* eslint-disable-line no-alert*/
/*eslint-disable-next-line no-alert*/
alert('foo');

3.3.2　ESLint插件开发实战

ESLint官方提供的校验规则大多是细粒度的原子型规则，我们可以自由地将其组合为自己需要的集合。但仅仅这样还不足以保障团队的代码质量，ESLint更多地是在多人协作开发中约束代码风格的一致性，它的约束范围有一定的限度，像是团队内部达成的约定或是最佳实践的沉淀，如果没有工具层面的保障，新人很有可能会因为不了解约定而无法写出符合要求的代码。如果我们将一些代码检视中反复出现的问题收集起来，并通过ESLint自定义插件来进行检查并给出提示，通常就能有效地减少代码检视中大量重复问题或低级问题的干扰，这样一来，开发者也能够将更多精力放在设计模式上或者深入业务场景打磨产品。这些才是开发人员真正需要去关注和思考的部分。

假设团队中的新人在编码时想要实现判断变量是否为数组的功能，但由于不熟悉ES6的语法，他可能并不知道直接使用Array.isArray()这个原生方法就能够实现该功能，于是转而使用Lodash提供的isArray方法，然而由于其不知道Lodash可以分模块引入指定方法，也不知道使用webpack插件可以在不修改代码的情况下达到同样的目的（使用lodash-webpack-plugin和babel-plugin-lodash），于是他直接全量引用了Lodash库，导致包体积增大。这种问题并不是错误，但类似的问题如果大量出现，势必会加重代码维护的负担，还可能影响构建产物的质量。笔者在实际工作中也曾遇到过这样的场景，在针对打包产物进行性能优化时，仅仅是针对Lodash体积的优化，就让打包产物的体积减小了近70KB，要知道完整的Vue2框架的大小也不过才80KB。

关于如何使用ESLint插件进行开发，可以参考笔者发表在掘金社区的文章《使用ESLint自定义插件保障团队最佳实践有效落地》，其中详细介绍了ESLint插件开发和使用的相关知识，本文中就不再展开讲解了。

3.3.3　初学者的修行

如果你是一名初学者，千万不要因为自己浏览了官方文档，并产出了一份能够生效的“.eslintrc”配置文件，就觉得自己已经掌握了ESLint，因为即使是非前端开发者也能轻松做到这一点。想要真正掌握它，需要更多的修炼。官方文档为每一条ESLint规则编写了非常详细的说明，并给出了对比示例代码，建议花点时间逐条仔细地去研究和学习，尽可能了解每条规则背后所隐藏的JavaScript语言的基础知识或编程原则。这是一个非常庞大的工程，不可能一蹴而就。比如，为了搞清楚一个简单的“eqeqeq”规则，可能需要花费很长的时间去学习“隐式类型转换”的知识，但是请不要跳过它们，很多从事前端开发工作好几年的工程师依然搞不清楚它底层所依赖的“抽象比较算法”是如何运行的。笔者在学习这些规则的时候，每天午饭后阅读5～10条规则，然后把有疑惑的部分记录下来，晚上下班后再花20min左右的时间查找资料，如果扩展资料太多就收藏下来等到周末统一消化，最终的效果非常好，因此强烈推荐这个方法，这样用一个月左右的时间就能学习完整个规则集。当你完成的时候，就会明白这样学习的意义所在。

上一章目录下一章