前言
编写代码的时候必要的编写规范还有格式，对代码的阅读还有避错都是有良好的帮助的。我们就来看一看帮助我们达到一些编码规范的工具ESlint吧。
正文
概要
ESlint是Espree来解析js的，通过抽象语法树（AST）来估算代码模板。它是一个完全插件话的，每一个单一的规定都是一个插件。
使用方式
我们可以很方便的通过npm来导入eslint来使用，当我们使用ESLint的时候我们往往会在根目录下面看到一个配置文件内容（.eslintrc）。这个文件是用来配置我们的eslint的。
我们配饰ESlint的时候主要通过两种方式。
- 注释配置：
我们可以在js文件之中使用特定的注释的形式来提示eslint此处的文件的格式配置 - 配置文件：
我们可以通过js, json, yaml文件来进行内容的设置或者我们也可以在package.json文件之中通过eslintconfig来进行内容的配置。最后还有一种方式是通过命令行的形式来进行内容的配置的，当然这种情况会相对少一点，eslint对于多重配置会自动的读取和设置，但是要提一句的就是，只有当找不到其他相关的内容，eslint最终才会使用根目录下的配置文件信息。
配置
我们现在来具体的说一说如何使用吧：
-
parserOptions：这是一个参数对象内容，主要用来设置相关的语法环境内容，或者可以选择使用jsx语法，我们可以通过这个对象之中如下属性来设置。
ecmaVersion来设置我们要是用的js的语法规范版本。sourceType参数可以设置是使用script或者module来控制语法形式。ecmaFeatures这个参数实际上也是一个对象，他可以设置当前语法的一些表现形式，是否可以在全局环境下返回啊，是否可以使用严格模式，或者语法使用jsx的形式。
-
parser：我们可以设置我们自己的语法解释器内容，默认的解释器是espree，我们常常会在项目之中设置称为babel-eslint来进行解析。同时我们也可能会用到@typescript-eslint/parser可以用来解析typescript。也有一些注意事项
- 如果我们设置了解释器的话，可能我们之前设置的解析选项将会不起作用。这一点要十分的注意。
- 第二点是我们需要配饰parser的话，我们需要注意我们的解释器要单独的下载下来。
- 最后一点是我们下载的解释器要符合解释器接口模式（parser Interface）
-
processor：插件可能会提供相关的处理机，帮助我们截取文件之中的js内容，或者预处理相关的信息文件内容。我们可以在plugin引入之后，通过overrides来设置相关信息的读取和处理形式，其中处理机的设置就是通过processor来设置的。files来设置当前处理机需要处理的文件有哪些，我们简单的来看一个示例吧。
{
"plugins": ["a-plugin"],
"overrides": [
{
"files": ["*.md"],
"processor": "a-plugin/markdown"
},
{
"files": ["**/*.md/*.js"],
"rules": {
"strict": "off"
}
}
]
}
-
env：我们接下来主要需要看的是环境的设置情况。eslint提供了很多的全局环境内容的引入，broswer,jest,node等等，通过设置这些参数来限制引入相关的全局参数内容。如果我们想要针对特定的plugins使用相关的全局变量的情况，可以通过
plugins名称/全局环境名称的形式在env之中设置。 -
globals：这个参数可以设置全局环境下的某一个参数读写操作的权限，例如当我们使用ES6的环境，但是promise不可以使用的情况，我们可以通过如下设置来达到。
{
"env": {
"es6": true
},
"globals": {
"Promise": "off"
//此处使用off表示全局环境之中不可见。
//还有false/readonly表示当前内容可读。
//true/writable表示当前参数可写,可读。
}
}
-
plugins：表示的是我们需要引入的插件内容。
-
rules： 最终要的一个配置内容来了，其中是键值对的形式，key是rule的id然后value的值有三种。
off关闭当前的规则。warn开启规则但是不强调，只是给与警告，并且不影响已存在的代码。error打开规则，并且在触发规则的时候推出代码执行并报错。- 我们引入了插件之后对于特定插件采用特定规则的时候我们可以通过
plugin名称/rule信息：rule状态的形式进行设置。 - 当我们希望某些规则针对某些文件不生效的时候我们可以在overrides之中进行内容的设置。上一段代码：
{ "rules": {...}, "overrides": [ { "files": ["*-test.js","*.spec.js"], "rules": { "no-unused-expressions": "off" } } ] } -
comments：我们之前说过可以通过配置的形式来配置eslint的设置，形如如下：
/* eslint eqeqeq: "off", curly: "error" */
当然我们也可以使用注释来取消某些行之中eslint的检查。我们可以通过如下代码设置：
/* eslint-disable no-alert, no-console */ //主要是eslint-disable
/* eslint-enable no-alert, no-console */ //恢复eslint职能
我们也可以值屏蔽单行的情况。
alert('foo'); // eslint-disable-line
-
settings：这个参数内容设置的是自定义参数内容，参数会传递给每一个规则。
-
配置优先级说明：
- 如果同层级之中有package.json和.eslintrc文件的话，eslint将会使用.eslintrc文件之中的配置。
- 如果当前文件夹的上层是有eslint的配置的情况，上层的配置情况将会自动的传递到当前路径下，并且结合当前文件夹之中所配置的eslint内容，并且优先使用当层配置情况。
- 当我们使用自己的配置文件的时候要十分注意因为eslint在没有配置相关生效文件信息的时候将会运用到全部的文件之中，包括第三方文件，这是我们需要注意的。
- 又与ESlint会向上查询所有的父路径信息，所以我们可以通过在文件之中配置root：true的形式来阻止eslint向上查找。
-
extends：继承已有的相关属性配置内容，eslint有一系列的现有规则的预设，我们可以使用extends来对当前的eslint内容进行规整。所以我们可以看到extends和plugins的不同在于，extends实际上是eslint本身预设的一些列已有规则的配置，plugins实际上是引入新的配置方式。
-
最后我们来尝试变来写一段简单的自定义eslint配置吧：
module.exports = {
root: true,
env: {
browser: true,
es6: true,
node: true,
},
extends: ['eslint:recommended'],
rules: {
"no-console": [1, { allow: ['error'] }],
"curly": [1, 'multi-line']
}
}
常见规则
上面是eslint的大部分规则配置内容，我们可以看到eslint是十分容易进行配置的形式，我们的我们可以定制化的对规则进行配置，当然了解上面的这些事不够的，我们还需要对一些常用的规则进行一些了解，这里我就直接贴上官方的规则列表内容，想要了解的朋友请点击这里
结束
工程化的开发是很重要的，针对于大型的项目的开发，一套说定的方案是远远不够的，还需要的强制化的进行一些约束条件，才能更好的规定当前的内容情况。随着之后的开发系统的大型，衔接的多元化，工程化将会越来越重要，eslint仅仅只是一个前端工程化的开始。然我们共同学习共同进步吧，拜拜。
