前面两节已经对eslint的配置,eslint源码进行了详细的解释,那接下来我们就来手写一个plugin。
该plugin包含自定义rule、自定义processor、共享配置信息。
完整的项目请看eslint-project
一、创建一个插件 - myPlugin
-
初始化项目。每个插件是一个命名格式为
eslint-plugin-<plugin-name>
的 npm 模块,你也可以用这样的格式@<scope>/eslint-plugin-<plugin-name>
限定在包作用域下。我们的插件就取名为eslint-plugin-myPluginmkdir myPlugin cd myPlugin npm init
-
在eslint中,插件可以暴露额外的规则以供使用。为此,插件必须输出一个rules对象,包含规则ID和对应规则的一个键值对。那我们就来自定义一个rule, id取名为replacement。rule解决的问题是将代码块中的XXX替换为Candice。
创建规则需要的属性以及每个属性对应的功能,eslint官网已经给出了详细的解释,这里我就不赘述了,不了解的同学可以移步官网。
创建自定义规则还需要掌握抽象语法树AST(Abstract syntax tree)的知识。
Eslint默认的语法解析工具为Espree,我们可以在AST explorer查看代码解析之后对应的节点类型。
-
创建myPlugin/rules/replacement.js
"use strict"; //------------------------------------------------------------------------------ // Rule Definition //------------------------------------------------------------------------------ module.exports = { // 规则的元数据 meta: { /** * type (string) 指示规则的类型,值为 "problem"、"suggestion" 或 "layout" * "problem": 指的是该规则识别的代码要么会导致错误,要么可能会导致令人困惑的行为。开发人员应该优先考虑解决这个问题。 * "suggestion": 意味着规则确定了一些可以用更好的方法来完成的事情,但是如果代码没有更改,就不会发生错误。 * "layout": 意味着规则主要关心空格、分号、逗号和括号,以及程序中决定代码外观而不是执行方式的所有部分。这些规则适用于AST中没有指定的代码部分。 */ type: "problem", // 对 ESLint 核心规则来说是必需的 docs: { // 展示在eslint规则首页的描述 description: "XXX 不能出现在代码中!", // eslint规则首页的分类: Possible Errors、Best Practices、Strict Mode、Varibles、Stylistic Issues、ECMAScript 6、Deprecated、Removed category: "Possible Errors", // "extends": "eslint:recommended"属性是否启用该规则 recommended: false, // 指定可以访问完整文档的URL url: "https://github.com/Candice0718/eslint-project/tree/master/myPlugin/rules" }, // 该规则是否可以修复 fixable: "code", // 参数类型 schema: [ { type: 'string' } ], messages: { unexpected: '错误的字符串XXX, 需要用{ {argv}}替换' } }, // 返回一个对象,Eslint在遍历抽象语法树AST时,用来访问节点的方法。 /** * */ create: function (context) { // 获取规则的参数 const str = context.options[0];
-