[JavaScript知识库]30 webpack中使用Eslint

Eslint

一个团队中每个人的编程习惯是不同的，那么项目中的代码就是各种风格的，这无疑增加了项目代码的维护成本。作为一个团队，应该有着统一的代码规范，让代码具有更高的可读性。单是靠程序员手动去修改不符合团队代码规范的代码，不仅耗时耗力，而且很少做到万无一失。这些代码规范的检测和修改应该交给程序帮我们去实现。本章节从JavaScript层面，介绍如何在Webpack中实现对JavaScript代码风格的格式化。

对于JavaScript代码格式的校验和修改，最常用的就是Eslint。使用Eslint，开发者可以自己指定项目的编码规范，当团队成员的代码不符合规范的时候，它可以给出警告提示，还可以使用其内置的功能，按照定义的规则去自动修改不符合规范的代码。在Webpack中要使用Eslint，需要安装Eslint和Eslint-loader。

一个简单的配置如下：

module.exports = {
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                loader: 'eslint-loader',
                options: {},
            },
        ],
    }
}

跟Bael-loader一样，Eslint也需要一个配置文件，该配置文件告诉Eslint该如何进行代码的校验，可以使用.eslintrc.* 文件，或者直接在package.json文件里的eslintConfig字段指定配置，EsLint会查找和自动读取它们，再者，你可以在命令行运行时指定一个任意的配置文件。先看一个官方的简单示例配置：

{
    "parserOptions": {
        "ecmaVersion": 6,
        "sourceType": "module",
        "ecmaFeatures": {
            "jsx": true
        }
    },
    "rules": {
        "semi": "error"
    }
}

该配置告诉了Eslint按照什么标准去校验相关代码，下面对Eslint的配置项的功能做一下简单的介绍。

Parser

Parser代表Eslint中使用的解析器，默认使用Espree作为其解析器，不同的解析器里面内置的解析规则也不一样。可以使用别人开发好的解析器或者使用自定义解析器。当你使用Babel-loader的时候，为了避免相关的解析错误，可以使用Babel-eslint解析器。

{
    "parser": "babel-eslint"
}

ParserOptions

解析器选项（parserOptions），用于对解析器进行更精细化的配置。

{
    "parserOptions": {
        // 使用babel-eslint解析器
        "parser": "babel-eslint",
        // 自定ECMAScript版本 ，在这里表示启用ES6语法，如果需要启用ES6全局变量，请使用env进行配置。 
        "ecmaVersion": 6,
        // 指定资源类型，设置为 "script" (默认) 或 "module"（如果你的代码是 ECMAScript 模块)。
        "sourceType": "module",
        // 备至启用额外的语言特性
        "ecmaFeatures": {
            // 启用 JSX
            "jsx": true,
            // 允许在全局作用域下使用 return 语句
            "globalReturn": true,
            // 启用全局 strict mode (如果 ecmaVersion 是 5 或更高)
            "impliedStrict": true,
            /**
    * 启用实验性的 object rest/spread properties 支持。
    * (重要：这是一个实验性的功能,在未来可能会有明显改变。
    * 建议你写的规则 不要 依赖该功能，除非当它发生改变时你愿意承担维护成本。)
    */
            "experimentalObjectRestSpread": true
        }
    }
}

Plugins

Eslint中可以使用第三方插件，比如使用Eslint-plugin-react插件来校验React代码，使用插件的时候，你需要安装该插件，然后把插件名称配置在Plugins中：

{
    "plugins": [
        "plugin1",
        "plugin2"
    ]
}

Processor

插件中可以提供处理器（Processor），处理器可以从另一种文件中提取JavaScript代码，然后让Eslint检测JavaScript代码。若要在配置文件中指定处理器，请使用Processor选项，并使用由插件名和处理器名组成的串接字符串加上斜杠：

{
    "plugins": [
        "a-plugin"
    ],
    "processor": "a-plugin/a-processor"
}

Environments

Environments用于指定全局可用的环境，使用env进行配置，比如用于浏览器和Node环境中的代码，可以进行如下配置：

{
    "env": {
        "browser": true,
        "node": true
    }
}

env支持多种环境的设置。

Globals

在项目文件中访问全局变量时，将会出触发Eslint中的no-undef规则并发出警告，可以在globals中进行全局变量的配置，告诉Eslint这些全局变量名称是可以使用的：

{
    "globals": {
        // writable表示可以重写变量
        "Jquery": "writable",
        // readonly表示只能使用变量
        "React": "readonly"
    }
}

Rules

Eslint中内置了许多规则，你可以修改这些校验规则或者新增一些规则，规则的配置操作是在rules中进行定义的：

{
    "rules": {
        "eqeqeq": "off",
        "curly": "error",
        "quotes": [
            "error",
            "double"
        ]
    }
}

off/0表示关闭规则,warn/1表示开启规则，出现错误发出警告，不会中断程序的执行，error/2也表示开启规则，但是出现错误的时候会中断程序的执行。更多rules的规则请前往https://eslint.bootcss.com/docs/rules/进行查阅。

Settings

使用Settings可以共享一些配置，它会被提供给每一个执行的规则：

{
    "settings": {
        "sharedData": "Hello"
    }
}

Root

默认情况下，Eslint会在所有父级目录里寻找配置文件，一直到根目录。为了将Eslint限制到一个特定的项目，在你项目根目录下的package.json文件的eslintConfig字段下或者 .eslintrc.* 文件里的设置 “root”: true。Eslint一旦发现配置文件中有 “root”: true，它就会停止在父级目录中寻找。如果项目中特定目录下面的资源文件需用使用不同的校验配置，就需要在特定目录下Eslint中的配置文件中进行如下配置：

{
    "root": true
}

避免规则覆盖使用而导致的错误。

Extends

使用Extends可以使得配置文件中的校验规则继承Extends所指向的配置中的规则。rules可以对继承的规则进行改造或者覆盖。

• Extends 属性值可以是： 指定配置的字符串(配置文件的路径、可共享配置的名称、eslint:recommended 或
  eslint:all)
• 字符串数组：每个配置继承它前面的配置

Extends还可以继承于插件中的配置，如下所示：

{
    "plugins": [
        "react" // 使用eslint-plugin-react插件
    ],
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ],
    "rules": {
        // 修改继承的规则
        "no-set-state": "off"
    }
}

.eslintignore

可以通过在项目根目录创建一个.eslintignore文件告诉Eslint去忽略特定的文件和目录。把下面 .eslintignore文件放到当前工作目录里，将忽略项目根目录下的node_modules，bower_components以及build/目录下除了build/index.js的所有文件：

# /node_modules/* and /bower_components/* in the project root are ignored by default
# Ignore built files except build/index.js
build/*
!build/index.js

使用注释

在特殊情况下希望Eslint跳过对相应代码的检测，除了修改配置规则，还可以使用注释的方式：

/* eslint-disable */
alert('foo');
/* eslint-enable */

这里表示该区域范围内的代码不会被Eslint中的所有规则所作用，如果你想使用一部分规则，可以进行如下配置：

/* eslint-disable no-alert, no-console */
const a = 1;
alert('foo');
console.log('bar');
/* eslint-enable no-alert, no-console */

表示该区域内的代码不能使用alert和console进行信息的输出。

下面给出本章节demo代码中的eslint配置：

{
    "parserOptions": {
        // 使用babel-eslint解析器
        "parser": "babel-eslint",
            // 启用es6语法
            "ecmaVersion": 6,
                // ECMAScript模块类型
                "sourceType": "module"
    },
    "rules": {
        // 使用alert报错
        "no-alert": "error",
            // 使用 == 警告
            "eqeqeq": 1
    }
}

值得注意的是，rules中配置的规则触发跟项目文件中代码书写的顺序有关。如果alert相关的代码在使用==操作符的代码之前，那么"eqeqeq": 1不会出现警告而是直接报错（报错才是正确的运行结果，因为使用alert已经报错了，中断后面的执行了），所以在自己配置Eslint规则的时候，如果没有出现预期的结果，有可能就是顺序的问题。

在package.json中的scripts字段中进行如下配置：

{
    "scripts": {
        "dev": "node scripts/dev.js",
        "lint": "eslint --fix --ext .js src"
    }
}

运行npm run lint就会把src中不符合rules规则的代码进行自动修复，该操作并不会修复所有的格式错误，只有符合相关规则的格式错误才会被修复。更多Eslint详细配置，请前往https://eslint.bootcss.com/docs/user-guide/configuring进行查阅。

如果你想对项目的Css代码也进行统一风格的设置，可以使用Stylelint，Stylelint是一个Css linter，其配置方式和使用技巧和Eslint大同小异，感兴趣的可以前往https://stylelint.io/进行查阅。

本章节提供案例源码下载:https://gitee.com/mvc_ydb/webpack/blob/master/codeLinter.zip