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 为例（虽然已有类似规则，这里用于演示）：
<strong>module.exports = {<br> meta: {<br> type: "suggestion",<br> docs: {<br> description: "禁止使用 console.log"<br> },<br> schema: [] // 规则不接受配置参数<br> },<br> create(context) {<br> return {<br> MemberExpression(node) {<br> if (<br> node.object.name === "console" &&<br> node.property.name === "log"<br> ) {<br> context.report({<br> node,<br> message: "不允许使用 console.log"<br> });<br> }<br> }<br> };<br> }<br>};</strong>这段代码监听 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 遍历机制。一旦掌握，就能按团队需要定制检查逻辑，提升代码质量。
