自定义 ESLint 规则测试器 - 编写并验证规则

在规则的 create 方法返回的对象中，你可以指定要监听的 AST 节点类型。当 ESLint 遍历到匹配的节点时，会调用你定义的回调函数，并将该节点作为参数传入。例如，要检查所有函数调用，你可以返回 { CallExpression(node) { ... } }，然后在回调中通过 node.callee 访问被调用的对象，通过 node.arguments 访问参数列表。每个节点类型都有其特定的属性结构，建议结合 AST 在线查看工具来了解不同节点类型的属性。

create 函数是 ESLint 规则的核心入口点。它在 ESLint 开始处理每个文件时被调用一次，接收 context 参数并返回一个对象。返回对象的键是 AST 节点类型名称，值是对应的处理函数。ESLint 在遍历 AST 时，每当遇到匹配类型的节点就会调用相应的处理函数。这种设计模式使得规则可以声明式地定义自己关心的代码结构，而无需手动遍历整棵 AST。create 函数还可以在闭包中维护状态，用于跨节点的复杂检测逻辑。

AST 是 ESLint 进行代码分析的基础数据结构。ESLint 使用解析器（默认为 espree）将源代码转换为 AST，树中的每个节点对应代码中的一个语法元素。自定义规则的本质就是定义一系列针对特定 AST 节点类型的检查逻辑。例如，检测 console.log 调用需要监听 CallExpression 节点，然后检查 callee 是否为 MemberExpression 且 object 名称为 console、property 名称为 log。理解 AST 的结构和节点之间的关系是编写高质量 ESLint 规则的前提条件。

调试自定义规则的最佳实践是：首先，使用在线测试器编写多个测试用例，包括应该触发违规的正例和不应该触发的反例。其次，在规则逻辑中可以使用 console.log 输出中间结果来追踪执行流程。第三，利用 AST 在线查看工具验证你对节点结构的理解是否正确。第四，逐步缩小检测范围，确保规则只匹配目标代码而不产生误报。最后，参考 ESLint 官方文档和现有规则的源码来学习成熟的调试技巧。在线测试器的即时反馈特性使得调试过程更加高效。

ESLint 规则常用的节点类型包括：Program（程序根节点）、ExpressionStatement（表达式语句）、CallExpression（函数调用）、MemberExpression（成员访问）、Identifier（标识符）、VariableDeclaration（变量声明）、IfStatement（条件语句）、FunctionDeclaration（函数声明）、ReturnStatement（返回语句）、AssignmentExpression（赋值表达式）等。每种节点类型对应代码中的一种语法结构，选择正确的节点类型是规则能否正确检测的关键。你可以通过 astexplorer.net 查看任意代码片段的 AST 结构，找到你需要监听的节点类型。

在线测试器在浏览器端使用 JavaScript 解释器模拟了 ESLint 的核心检测流程。它首先将测试代码解析为 AST，然后遍历 AST 中的每个节点，检查是否有匹配自定义规则选择器的节点。当匹配到目标节点时，执行规则中定义的回调函数，如果回调函数调用了报告方法，则记录一条违规信息。整个过程与 ESLint 的实际检测逻辑基本一致，确保了在线测试结果的可靠性和参考价值。

context 对象是规则与 ESLint 运行时交互的桥梁，常用方法包括：context.report() 用于报告违规并触发检测结果；context.getSourceCode() 获取源代码对象，可进一步获取 AST、令牌、注释等信息；context.getFilename() 获取当前处理的文件名；context.getScope() 获取当前作用域信息，用于变量分析；context.getAncestors() 获取当前节点的所有祖先节点。此外，通过 sourceCode 对象还可以使用 getCommentsBefore()、getText() 等方法获取更细粒度的代码信息。

ESLint 和 Prettier 虽然都是代码质量工具，但定位截然不同。ESLint 是静态代码分析工具，专注于检测代码中的潜在问题、逻辑错误和编码规范违规，例如未使用的变量、隐式类型转换、特定 API 的禁止使用等。Prettier 是代码格式化工具，专注于统一代码的视觉呈现风格，如缩进、引号、分号、换行等。两者可以互补使用：ESLint 处理代码质量和逻辑规范，Prettier 处理代码格式。自定义 ESLint 规则测试器帮助你编写属于团队特有的代码质量规则，而格式化类需求建议交由 Prettier 处理。

避免误报是规则开发中的重要课题。首先，使用精确的选择器而非过于宽泛的匹配。例如，检测 console.log 时应同时检查 callee 的 object 和 property，而不是只匹配所有 CallExpression。其次，利用作用域分析排除特殊情况，如检测未使用的导入时需考虑 re-export 场景。第三，收集团队实际代码中的边界案例，在测试用例中覆盖这些场景。第四，遵循 ESLint 社区的规则编写最佳实践，如使用 context.getScope() 进行变量追踪而非简单的文本匹配。第五，在发布前进行充分的灰度测试，收集真实反馈并持续优化规则逻辑。