Eslint

同类工具对比

相对其他语言来说Lint工具在JavaScript显得尤为必要，主要有以下几个原因:

• JavaScript被设计的过于灵活写法太多导致个人代码风格不一致；
• JavaScript设计缺陷较多比如和=，比较容易造成错误。
  ESLint诞生之前已经有几款JavaScript校验工具JSLint、JSHint、JSCS，目前ESLint是使用最广泛的JavaScript校验工具。四款工具对比如下
  
  Eslint最大的特点就是可扩展性，对于本来不支持的语法可以通过自定义解析器或者开发插件达到想要的功能，如支持ES6、JSX、TS等，也是基于此原因Eslint才大获成功。

基本使用

命令行使用

npm i -g eslint
eslint [options] [file|dir|glob]*

使用eslint可以指定检测某个文件某个路径或者全局，options可以通过eslint -h查看所有选项，里面包含对环境、规则、解析器等配置。不指定的话都是用默认规则。

规则

Eslint自带了很多规则，而且对这些规则做了分类如变量类，最佳实践类完整列表见Eslint完整规则，其中当使用"extends": "eslint:recommended"时就会打开所有前面带✅的规则，而使用eslint --fix是可以自动修复前面带🔧的规则。当这些规则满足不了我们的需求时我们就可以借助第三方插件或者自己实现插件的形式来解决。

配置文件

实际项目开发一般会采用配置文件的形式来指定各种规则，配置文件支持的格式包含JavaScript、JSON 或者 YAML，也可以添加eslintConfig到package.json中。

{
    "parserOptions": {
        "ecmaVersion": 6, // es版本默认是5，如果使用es6则指定6
        "sourceType": "module", // 默认script，如果使用es6Module则指定module
        "parser": "@typescript-eslint/parser", // eslint使用的解析器，默认是Espree，指定@typescript-eslint/parser则可以使用eslint校验ts
        "env": { // 一个环境定义了一组预定义的全局变量。可用的环境包括browser/node/es6等几十个
         browser: true, // 指定了browser为true就可以使用全局变量window document等
        },
        "ecmaFeatures": { // ecm相关的其他特性
            "jsx": true // 支持jsx
        }
    },
    // plugin则提供了除预设之外的自定义规则，当你在eslint的规则里找不到合适的的时候,使用第三方插件首先npm安装对应插件，然后这这里引用，其中eslint-plugin-可以省略
    "plugins": [ 
        "vue",
        "eslint-plugin-prettier"
    ]，
    // extend提供的是eslint现有规则的一系列预设
    //字符串或数组("extends": ["eslint:recommended","'plugin:vue/recommended'"]) 继承某个配置，可以是eslint自带的，可以是第三方插件
    // 如果extend的两个配置之间有冲突，则后面的覆盖前面的
    "extends": "eslint:recommended" 
    // 如果与extend中的配置值有冲突会覆盖extend中的配置
    "rules": { // 配置某条规则
        "semi": "error"
    }
}

忽略检测

• 可以通过配置.eslintignore文件忽略某个文件/路径的检测

/build/
/config/
/dist/

​

• 忽略某一行或多行检测

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

​

• 忽略某一行或多行的一条规则检测

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

自动修改

概述

Eslint检测出不符合规范的代码就会报错，但是如何去修改这些错误呢?

根据报错位置手动修改肯定是可以的，但是太浪费时间，这时候自动修复错误就出场了。
注意: lint工具规则可以分为两类
1.代码格式问题(Formatting rules),如空格数/单双引号/单行最大字符数；
2.代码质量问题(Code-quality rules),如未使用变量/没有返回值/双等号等。

修复方式

自动修复一般只修复第一类，目前有以下几种自动修复方案

只使用eslint

node_modules/.bin/eslint --fix fileName/fileDir(使用本地eslint) eslint --fix fileName/fileDir(使用全局)
配合编辑器

已vscode为例: 安装vscode插件并打开 Auto Fix On Save
Prettier

Prettier是一个代码格式校验/修复工具,但是Eslint本身有代码格式化的功能了，为什么还需要引入Prettier呢?

答案是Prettier在代码格式校验/修复方面更加强大(如果你觉得eslint的修复功能够用的话不用Prettier也是可以的)

例如: 单行最大字符数，使用Eslint --fix就无法自动修复

export default function isFromCustomer(message) {
return message.from === 'customer' || message.contactType === 'contactTypeMap.CUSTOMER' || message.contactType === 'contactTypeMap.REVEIVE_BY_ROBOT'
}

而使用Prettier时会自动修复成如下:

export default function isFromCustomer(message) {
  return (
    message.from === 'customer' ||
    message.contactType === 'contactTypeMap.CUSTOMER' ||
    message.contactType === 'contactTypeMap.REVEIVE_BY_ROBOT'
  );
}
​

使用Prettier有个问题就是，可能Prettier的规则跟eslint有冲突，解决方案是将Prettier的规则覆盖eslint的代码格式规则，让eslint专注于代码质量问题。配置方式如下

npm install --save-dev eslint-config-prettier eslint-plugin-prettier

{
"plugins": ["prettier"],
  "extends": [
    "eslint:recommended",
    "prettier", // prettier在最后面
  ]
}
​