ESLint插件开发需创建含rules、configs的npm包，如eslint-plugin-myteam；编写规则函数遍历AST节点，例如禁止console.log需监听MemberExpression并用context.report报错；通过RuleTester测试有效与无效代码案例；发布后在.eslintrc中启用，建议命名清晰、提供recommended配置、支持自动修复，掌握AST遍历即可定制化代码检查。
想让团队的JavaScript代码风格统一、减少低级错误，ESLint是目前最主流的静态分析工具。但标准规则无法覆盖所有业务场景，这时候就需要开发自定义插件来满足特定需求。下面讲清楚怎么从零开始做一个ESLint插件。
理解ESLint插件结构
ESLint插件本质上是一个npm包，导出特定结构的对象。核心包括：rules（自定义规则）、configs（可共享配置）、environments（环境变量）。最常见的需求是添加新规则。
一个插件的基本目录结构如下：
比如插件名为 eslint-plugin-myteam，使用时就写成 myteam/rule-name。编写一条自定义规则
每条规则是一个函数，接收上下文对象，返回一个对象，描述如何遍历AST节点并报告问题。
立即学习“Java免费学习笔记（深入）”；
以禁止使用 console.log 为例（虽然已有类似规则，这里用于演示）：
module.exports = {
meta: {
type: "suggestion",
docs: {
description: "禁止使用 console.log"
},
schema: [] // 规则不接受配置参数
},
create(context) {
return {
MemberExpression(node) {
if (
node.object.name === "console" &&
node.property.name === "log"
) {
context.report({
node,
message: "不允许使用 console.log"
});
}
}
};
}
};这段代码监听 AST 中的 MemberExpression 节点，判断是否为 console.log 调用，如果是，通过 context.report 报告错误。
测试与发布插件
写完规则后不能直接用，得验证它是否准确。ESLint 提供 eslint-rule-tester，可在单元测试中模拟代码片段检查行为。
在测试文件中：
- 引入 RuleTester 和要测的规则
- 定义测试用例：有效的代码（不会报错）和无效的代码（应触发错误）
- 运行测试确保逻辑正确
确认无误后，把插件发布到 npm。团队成员安装后，在 .eslintrc 中添加插件名和启用规则即可生效。
实用建议
开发过程中注意几点：
- 规则命名清晰，避免歧义，如 myteam/no-console-log
- 提供默认推荐配置（configs.recommended），方便一键启用
- 利用 meta.fixable 支持自动修复（fix 函数）
- 文档写清楚规则目的和示例
复杂规则可以结合 ESLint 提供的 getSourceCode() 获取原始代码信息，做更精细判断。
基本上就这些。ESLint 插件开发门槛不高，关键是理解 AST 遍历机制。一旦掌握，就能按团队需要定制检查逻辑，提升代码质量。
