ESLint中no-restricted-imports规则的正确使用姿势

在大型前端项目中，我们经常需要规范模块的导入方式，避免开发者直接引用某些内部实现细节。ESLint的no-restricted-imports规则就是为此而设计的，但它的模式匹配行为可能会让开发者感到困惑。

问题背景

当我们需要限制从特定目录导入时，比如禁止从TypeScript编译输出的lib目录直接导入，但又要允许其中的某些特定路径，配置起来并不直观。很多开发者会尝试使用类似.gitignore的排除语法，但发现效果不如预期。

核心原理

no-restricted-imports的patterns选项遵循.gitignore规范，这意味着：

1. 一旦父目录被排除，就无法单独重新包含其中的子文件
2. 必须按照特定顺序和方式声明排除规则才能达到预期效果

实战配置方案

假设我们有一个@org作用域下的多个包，需要：

1. 禁止从lib目录及其子目录导入
2. 但允许lib/下特定路径的导入

正确的配置方式应该是：

"no-restricted-imports": [
  "error",
  {
    patterns: [
      {
        group: [
          "@org/*/**",  // 首先禁止所有深层导入
          "!@org/package-one/lib/",  // 然后允许整个lib目录
          "!@org/package-one/lib/allowed/",  // 再允许allowed目录
          "!@org/package-one/lib/allowed/**",  // 最后允许allowed下的所有内容
          // 对其他包重复相同模式
          "!@org/package-two/lib/",
          "!@org/package-two/lib/allowed/",
          "!@org/package-two/lib/allowed/**"
        ],
        message: "请使用公共API，不要直接引用内部实现"
      }
    ]
  }
]

关键要点

1. 目录级排除优先：必须先排除整个目录，才能排除其中的特定子目录
2. 顺序很重要：排除规则需要从宽泛到具体逐步细化
3. 尾部斜杠：在排除目录时使用尾部斜杠可以明确表示这是一个目录而非文件
4. 通配符使用：**表示递归匹配所有子目录和文件

最佳实践建议

1. 对于大型项目，建议将这类配置提取到共享的ESLint配置中
2. 配合TypeScript的path映射，可以更好地控制模块导入
3. 在README或项目文档中明确记录允许的导入路径
4. 定期审查例外规则，避免例外过多导致规则失效

通过正确配置no-restricted-imports规则，可以有效维护项目的模块边界，保证代码架构的清晰性，同时保留必要的灵活性。