理解 ESLint 插件与规则的配置机制
在前端开发中，eslint 是一个不可或缺的代码质量工具。它通过一系列规则来检查代码，确保代码风格统一和潜在问题的发现。eslint 的强大之处在于其可扩展性，通过插件（plugins）可以引入社区或自定义的规则集，以适应各种项目需求。
然而，一个常见的场景是：我们可能只需要某个插件中的一两个特定规则，但如果直接使用插件提供的 extends 配置（例如 plugin:import/errors），它通常会引入一整套预定义的规则，这可能导致我们不得不手动禁用大量不必要的规则，增加了配置的复杂性。
例如，对于 eslint-plugin-import 插件，如果我们的目标仅仅是启用 import/named 规则来检查命名导入的正确性，但又不想引入 plugin:import/errors 中包含的其他如 import/no-unresolved 等规则，就需要一种更精细的配置方法。
避免引入预设规则集的方案
要实现仅启用插件中的特定规则，核心在于理解 plugins 和 extends 的区别。
- plugins 配置项的作用是注册 ESLint 插件，使其提供的规则对 ESLint 可见。
- extends 配置项的作用是继承一组预定义的规则集。这些规则集通常由插件本身或共享配置提供，它们会启用并配置插件中的多条规则。
因此，如果我们不想继承插件的预设规则集，最直接且最简洁的方法就是不使用或移除 extends 配置项。
示例配置
以 eslint-plugin-import 和 import/named 规则为例，以下是实现仅启用 import/named 规则的最小化配置：
{
"plugins": [
"import"
],
"rules": {
"import/named": "error"
// 您可以在这里添加其他需要启用的规则，无论是来自 'import' 插件还是其他 ESLint 核心/插件规则
},
// ... 其他 ESLint 设置，如 parser, env, settings 等
}配置解析：
- "plugins": ["import"]: 这一行是必不可少的。它告诉 ESLint 加载 eslint-plugin-import 插件，从而使得该插件提供的所有规则（如 import/named, import/no-unresolved 等）对 ESLint 引擎可用。
- "rules": { "import/named": "error" }: 这是关键所在。我们直接在 rules 配置项中指定要启用的 import/named 规则，并将其级别设置为 "error"（也可以是 "warn" 或 0/"off"）。通过这种方式，我们只启用了这一条规则，而没有引入 extends: ['plugin:import/errors'] 所带来的其他规则。
为什么这种方法有效？
当您移除 extends 配置时，ESLint 不会加载任何预设的规则集。它只会根据 plugins 数组注册插件，然后根据 rules 对象中明确指定的规则来执行检查。这意味着，如果您只在 rules 中定义了 import/named，那么只有这条规则会被激活。其他未在 rules 中明确定义的插件规则将保持禁用状态。
适用场景与注意事项
适用场景：
- 高度定制化需求： 当您对项目的 ESLint 规则有非常具体的定制需求，只想使用某个插件的少数规则，而不希望被其默认配置所束缚时。
- 与其他工具或规则集冲突： 当插件的默认规则集与项目中已有的其他 Linter 或规则集（如 TypeScript ESLint 推荐配置）存在冲突，且难以通过禁用解决时。
- 逐步引入规则： 在大型项目中逐步引入 ESLint 规则，希望每次只增加少量规则以控制影响范围时。
注意事项：
- 功能完整性： 某些插件的规则可能相互依赖或构成一个逻辑整体。如果只启用其中一条，可能会导致某些功能检查不完整或产生误报。在选择仅启用特定规则时，请确保您理解该规则的上下文和依赖。
- 手动维护： 这种方法意味着您需要手动维护所有启用的插件规则。如果插件发布了新规则或更新了推荐配置，您需要手动评估并决定是否将其添加到您的 rules 配置中。相比之下，使用 extends 并定期更新插件版本，可以更方便地获取最新的最佳实践。
- 性能影响： 虽然 plugins 数组会加载整个插件，但只有在 rules 中启用的规则才会实际执行检查。因此，对于性能的影响通常可以忽略不计。
总结
通过移除 extends 配置并直接在 rules 中声明所需规则，ESLint 开发者可以实现对插件规则的极致精细化控制。这种方法简洁高效，特别适用于那些只需要插件中特定功能，而不愿承担其完整规则集带来的额外配置负担的场景。然而，在采用此策略时，也应权衡功能完整性和手动维护成本，确保项目代码质量得到有效且合理的保障。
