eslint帮你做一个优雅的前端开发者前言刚开始做前端的时候，导师没有急着让我写代码，而是丢给我了一个非常有趣的任务-

前言

刚开始做前端的时候，导师没有急着让我写代码，而是丢给我了一个非常有趣的任务--如何优雅的使用vscode？这个问题搞得我有点懵，因为它根本就没有一个标准答案，你不知道做到什么程度才算优雅！

万般无奈之下，我打算先搞清楚何谓优雅？下面是词典上对优雅的解释，简单总结一下：优雅即优美雅致，给人一种心旷神怡的感觉。那我想用到vscode上面，就是如何写出让人心旷神怡的代码！首先代码的技术含量不说，不管你代码的算法多精妙，设计模式多合理，如果你代码的结构很乱，就会给人一种杂乱无章的感觉，可能你的技术很强，但就是不够优雅！

先说一下当年我对这个任务的完成情况，参照上面的标准的话可以说完成的十分不好，因为结果一点都不优化，反而很粗暴，我只是随便下载了几个网上热度很高的vscode插件，简单的了解了一下它们的功能，就放那不管了，后来导师见我对这个问题不怎么上心，也就没再说什么了。直到后来跳坑，才深切的体会到优雅带来的不只是感官上的愉悦，还有切实的好处！

说到这，我们今天的主角也呼之欲出了，没错，那就是大名鼎鼎的eslint，我们简单的回顾一下Eslint的发展史，了解下它是什么，可以做什么。

eslint的神秘面纱

1、由来

我们都知道javascript是其作者花费10天时间设计出来的，所以它本身存在很多缺陷，这就导致了我们在使用它的时候，会不经意的犯一些语法错误。所以最早针对js语法的检查工具就诞生了--jslint，该工具由 Douglas Crockford开发(也是《JavaScript：语言精粹》的作者)。它的缺点是语法规则都是预设的，用户无法改变。也就是说，想要使用这个工具，你必须确保自己能接受它的所有规则。

2. JSHint

JSHint 是由 Anton Kovalyov 基于 JSLint 开发的开源项目，显著的特点就是允许用户自定义自己的语法规则，加持上开源社区的驱动，发展十分迅速。由于是基于 JSLint 开发，原有的一些问题也继承下来了，比如：不易扩展，不易直接根据报错定位到具体的规则配置等。

3. ESLint

ESLint是由 Nicholas C. Zakas (《JavaScript 高级程序设计》作者) 在2013年开始开发的，它的初衷就是为了能让开发者能自定义自己的 lint rules，它提供了一套完善的插件系统，可以自由的扩展，动态的加载配置，同时能方便的根据报错定位到具体的规则配置。ESLint的诞生并不是 Zakas 在重复造一个轮子，而是他在业务开发中需要新增一条规则，但是 JSHint 无法提供支持，于是他就结合 JSHint 和 JSCS (AST的方式进行规则检测) 写出来了 ESLint。

早期的 ESLint 并没有大火，因为需要将源代码转成 AST，运行速度上输给了 JSHint，并且 JSHint 当时已经有了完整的生态（编辑器的支持）。真正让 ESLint 大火是因为 ES6 的出现。

ES6 发布后，因为新增了很多语法，JSHint 短期内无法提供支持，而 ESLint 只需要有合适的解析器就能够进行 lint 检查。这时 Babel 为 ESLint 提供了支持，开发了 babel-eslint，让 ESLint 成为最快支持 ES6 语法的 lint 工具。

看了eslint的发展史，我们知道它是用来校验代码语法和样式的，可以提升代码的安全性，优化代码样式，这不就符合我们提升代码优雅性的需求了吗？下面我们来看下该如何使用它？

eslint使用

在介绍eslint的用法之前，先提供一下项目结构，方便大家自己做测验。

先看一下上面代码存在的问题。首先是语法问题，我们没有定义变量c和d，确直接使用它们，却没有错误提示。其次，是我们定义的demo函数格式实在是难看，同样也没有什么提示。这样的代码看起来不仅不安全，也不优雅。

基于此，我们要实现的目标是：当保存代码时，自动通过eslint来校验代码格式，如果有错误可以自动修复非语法上的错误（修复代码样式的错误）

为了实现这个目标，我们来看一下vscode中eslint插件的功能介绍，可以看到vscode提供了保存代码时用eslint插件格式化代码的功能，只需要在项目的.vscode/setings.json文件中输入下面代码即可。

"editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
},

在vscode中安装了eslint插件以后，我们还需要通过npm安装eslint工具包才行，你可以通过npm i eslint命令安装，安装完毕以后，我们在项目下新建.eslintrc.js文件，并输入eslint的校验规则，这些规则将用来校验代码语法错误和样式问题。

下面我们看一下.eslintrc.js中的配置，我们主要对关键的root，extends、plugins和rules属性进行说明。

root

默认情况下，ESLint 会在所有父级目录里寻找配置文件.eslintrc.*，一直到根目录。如果你想要你所有项目都遵循一个特定的约定时，使用root属性即可。在你项目根目录下.eslintrc.* 文件里设置 "root": true。ESLint 一旦发现配置文件中有 root: true，它就会停止在父级目录中寻找，下面我们看一个例子。

module.exports = {
  root: true,
  // 下面省略
  .......
}

假设项目结构如下图所示，对于main.js文件的格式化，就依赖于与他同层次的.eslintrc.js配置，因为其配置中存在root: true，所以不在向上搜寻，project目录下的.eslintrc.js不在使用

extends

一个配置文件可以被基础配置中的已启用的规则继承，即extends；你可以把这个属性理解为递归调用并融合校验规则。举个例子，假设我在文件a里面定义了lint校验规则，我们b文件中通过extends引用文件a的规则，eslint则会将a和b中的规则进行融合，然后统一参与校验，下面我们来看一下extends可以接收哪些参数：

// eslint自带推荐的规则
"extends": "eslint:recommended"

// eslint自带所有校验规则
"extends": "eslint:all"

// 可共享的配置，是一个 npm 包，它输出一个配置对象。
例如：extends: standard

// 插件，是一个 npm 包，通常输出规则。
例如："extends": ["eslint:recommended","plugin:react/recommended"]

//本地的配置文件路径
"extends": "./eslint-config.js"

通过前面两个参数，我们可以引入eslint自身提供的一些校验参数；通过中间两个的引入方式，我们可以通过npm引入一些公共的，较好的校验规则；通过最后一种引入方式，我们则可以引入本地的校验规则。

plugins

plugins也是用来引入校验规则的，大多用于引入校验js文件以外的校验规则（extends用于引入js文件的校验），用法与extends第三种引入方式一致。比如，我想引入react文件的校验规则，则可以通过下年的方式。

"plugins": [
    "react" // "react"（省略写法） === "eslint-plugin-react"
]

rules

rules是干什么用的呢？假设我通过"extends": "eslint:recommended"引入了eslint自带的校验规则，但是我不想引用其中的某一个规则，此时我们就可以通过rules属性来关闭这个规则，用法如下，我们关闭了下面五条校验规则（规则的值为0或off）。同理，我们也可以通过rules，开启某个校验规则，输入参数为1既可以。讲到这里你可以明白，rules的优先级是最高的，可以覆盖extends设置的校验规则

module.exports = {
  root: true,
  extends: [],

  rules: {
    'space-before-function-paren': 0,
    'no-new-func': 'off',
    'no-prototype-builtins': 'off',
    'no-new': 0,
    'no-case-declarations': 0
  }
}