玩转ESLint自定义规则

在工作中为了团队的编码规范，往往代码的检测是必不可少的一个环节，那么避免不了的就要接触一些代码规范的工具，比如：ESLint、Prettier等工具。如果想针对业务设定不一样的规则，应该如何去自定义？请看官听我细细道来。

初始化demo

使用 npm 安装 ESLint：

$ npm install eslint --save-dev

创建配置文件：.eslintrc

{
   "parser": "esprima",  // 默认的解析器
   "rules": {
       "semi": ["error", "always"],
       "quotes": ["error", "double"]
   }
}

在package.json中添加命令

"script": {
	"lint": "eslint -c ./.eslintrc --rulesdir ./my-rules/rules/file.js index.js"
}

--rulesdir官网解释：这个选项允许你指定另一个加载规则文件的目录。这允许你在运行时动态加载新规则。

一切看似很平静，项目初始化工作已经准备的差不多了。想必有人就会迫不及待的运行下npm run lint，当然报错了。看官莫着急，且听下面分析。

创建自定义规则

my-rules目录结构

my-rules
  |—— rules
     |—— file.js 

file.js

module.exports = {
  meta: {
    docs: {
      description: '描述',
    },
    fixable: null, // TODO 代码修复
  },
  create(context) {
    return {
      MemberExpression(node) {  // 遍历ast的节点
        context.report({
          node,
          message: '错误描述信息',
        })
      },
    }
  },
}

看到这里是不是很好奇MemberExpression()是什么函数？为什么create返回的对象，函数什么时候调用？又为什么可以遍历到代码里的节点？

关于默认解析器解析的ast可以看这里espree: https://astexplorer.net/

关于ast的生成和遍历这里就不做过多的说明，有感兴趣的同学可以了解下编译器的原理，了解下如果分析代码，如何形成token，到ast，最终再生成代码的过程。

接下来就是修改配置文件：.eslintrc

 {
    "parser": "esprima",  // 默认的解析器
    "rules": {
        "semi": ["error", "always"],
        "quotes": ["error", "double"]
+       "file.js": "error" 
    }
}

到这里，自定义ESLint规则已经可以实现了。感兴趣的小伙伴可以动手试试。在项目本地新增自定义规则而不用发npm包。(欢迎小伙伴一起讨论，可以关注: coding前端)