ESLint插件开发：为什么不应直接调用核心规则

在ESLint插件开发实践中，许多开发者试图通过直接调用ESLint核心规则来实现规则扩展功能。这种做法虽然看似方便，但实际上存在严重的技术风险和维护隐患。本文将深入分析这一问题的本质，并探讨正确的解决方案。

问题背景

许多流行的ESLint插件（如typescript-eslint和eslint-plugin-unicorn）都曾尝试通过访问ESLint内部API来调用核心规则。典型的实现方式是通过eslint/use-at-your-own-risk模块获取内置规则，然后在自定义规则中调用这些规则的实现逻辑。

这种做法的初衷是可以理解的：开发者希望创建与核心规则行为一致但又有特殊处理的"扩展规则"。例如，TypeScript特定的类方法使用检查规则可能需要在ESLint核心规则基础上增加对TypeScript语法的支持。

技术风险

直接调用核心规则存在几个关键问题：

1. API稳定性风险：ESLint核心规则属于内部实现细节，其API结构和行为可能在任意版本中发生变化，不受语义化版本控制的保护。

2. 未来兼容性问题：ESLint团队已明确表示计划将核心规则移出主包，届时所有依赖此实现的插件都将无法工作。

3. 维护困难：当核心规则更新时，依赖它们的插件可能无法及时同步这些变更，导致行为不一致或潜在冲突。

官方立场

ESLint团队对此有非常明确的立场：强烈反对插件直接调用核心规则。builtinRules导出项的存在只是为了向后兼容，而非鼓励这种用法。官方文档即将更新，以最强烈的措辞警告开发者不要采用这种模式。

推荐解决方案

正确的做法是完全复制核心规则代码到插件项目中，然后进行必要的修改。虽然这会增加维护负担，但这是唯一可持续的方案：

1. 完全控制：复制规则代码后，开发者对规则行为有完全控制权，不受ESLint核心变更影响。

2. 明确责任：这种做法明确了扩展规则的维护责任边界，避免与核心规则产生混淆。

3. 更新策略：建议设置定期（如每两周与ESLint发布周期同步）的检查机制，决定是否合并核心规则的更新。

实施建议

对于需要扩展核心规则的场景，建议采用以下工作流程：

1. 从ESLint源码中复制目标规则的完整实现
2. 在插件项目中创建新的规则文件
3. 根据需求修改规则逻辑
4. 建立定期同步机制，评估是否合并核心规则的更新
5. 在文档中明确说明这是核心规则的修改版本

结论

虽然直接调用核心规则在短期内看似方便，但从长期维护和稳定性角度看，这种做法存在重大风险。ESLint插件开发者应当采用复制+修改的策略来实现规则扩展，尽管这会增加初期的工作量，但能确保插件的长期稳定性和可维护性。ESLint团队将持续强化这方面的文档指导，帮助开发者采用正确的方式实现规则扩展需求。