强制执行 ESLint 规则：驯服代码库混乱的指南

eslint-disable-inserter

eslint-disabled-stats

在瞬息万变的 JavaScript 开发领域，ESLint 在维护代码质量方面发挥着至关重要的作用。当开发者安装 ESLint 或引入新的规则时，它通常会发现大量错误。那么，该如何处理这些错误呢？

📝 太长不看

1. 使用错误来创建阻塞规则，并在您的持续集成 (CI) 中强制执行这些规则。
2. 使用类似这样的脚本注释掉所有现有的 ESLint 错误eslint-disable-inserter。
3. 请尽快合并此问题，以防止出现新的错误。
4. 然后按照自己的节奏改正错误。

⚠️警告的诱惑️

当开发者第一次遇到 ESLint 错误时，文件中大量的违规情况可能会令人望而生畏。有些人可能会试图将这些错误转换成警告，以便快速通过代码检查，而忽略了根本问题。

这是一种糟糕的做法，它无法阻止新错误的出现。开发人员将无法分辨哪些是可接受的警告，哪些是伪装成警告的错误。

⚔️ 另一个误区：试图一次性解决所有问题

有些开发者可能会倾向于在将新的 ESLint 规则应用到代码库之前，先修复所有现有错误。虽然这种做法看似合乎逻辑，但往往会导致大量的 pull request，难以审查和重新基于现有代码。在开发者努力修复错误的同时，其他人可能又会引入新的错误，使之成为一场永无止境的战斗。

🤖 更好的方法：eslint-disable-inserter

为了解决这个问题并简化新规则的使用，我创建了eslint-disable-inserter，这是一个 npm 包，可以简化对现有 ESLint 错误的注释。

export const MyComponent = () => {
  let count = 0
  count += 1
  const messages: any = undefined
  return (
    <div>
      <h1>MyComponent</h1>
      <p>Count: {

eslint-disable-inserter工作原理

eslint-disable-inserter它会自动在代码中插入// eslint-disable-next-line ...或添加注释，从而消除现有的 ESLint 错误。它支持 JSX 检测，并且是幂等的，允许重复使用而不会产生重复代码。{/* eslint-disable-next-line ... */}

示例：转换代码

假设您有以下存在 ESLint 违规的 TypeScript 文件：

export const MyComponent = () => {
  let count = 0;
  count += 1;
  const messages: any = undefined;
  return (
    <div>
      <h1>MyComponent</h1>
      <p>Count: {count + messages.myMessage}</p>
      {/* eslint-disable-next-line eqeqeq -- my comment */}
      <p>Is Zero: {count == 0 ? messages.yes : messages.no}</p>
    </div>
  );
};

运行以下命令：

eslint --format json . | eslint-disable-inserter

将文件转换为：

export const MyComponent = () => {
  let count = 0;
  count += 1;
  // eslint-disable-next-line @typescript-eslint/no-explicit-any -- FIXME
  const messages: any = undefined;
  return (
    <div>
      <h1>MyComponent</h1>
      {/* eslint-disable-next-line @typescript-eslint/no-unsafe-member-access -- FIXME */}
      <p>Count: {count + messages.myMessage}</p>
      {/* eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, eqeqeq -- FIXME my comment */}
      <p>Is Zero: {count == 0 ? messages.yes : messages.no}</p>
    </div>
  );
};

♻️ 按照自己的节奏全部解决

您已为所有现有的 ESLint 错误添加了明确的注释，并且不会再添加新的错误。

现在您可以和您的团队一起决定如何处理这些遗留问题以及如何解决这些问题。

您可以使用我创建的另一个软件包来可视化任务的大小：eslint-disabled-stats

$ npx eslint-disabled-stats -g -p "example/**/*.(js|ts)"

ℹ Analysing 2 files...
✔ Statistics computed

Rules disabled by rule:
• prefer-const: 1
• eqeqeq: 1
• curly: 1
• ALL_RULES: 1

Rules disabled by file:
• example/index.ts: 3
• example/legacy/legacy-file.js: 1

Total rules disabled:  4

Analysed files:        2
Analysed lines:        19

✔ Done

$ npx eslint-disabled-stats -g -p "example/**/*.(js|ts)"

ℹ Analysing 2 files...
✔ Statistics computed

Rules disabled by rule:
• prefer-const: 1
• eqeqeq: 1
• curly: 1
• ALL_RULES: 1

Rules disabled by file:
• example/index.ts: 3
• example/legacy/legacy-file.js: 1

Total rules disabled:  4

Analysed files:        2
Analysed lines:        19

✔ Done

根据修复错误的预计时间，您可以批量修复，也可以选择童子军式方法。

用童子军式的方法，你可以在修改代码后让代码库变得更干净。

在日常工作中，遇到错误就及时修复。只有充分了解代码上下文，才能有效解决错误，这样可以降低回归风险。

为了确保代码库质量的持续改进，请务必不要接受任何带有注释的 ESLint 错误的 Pull Request。一些工具可以帮助您自动执行此审查步骤，例如Danger JS。

您还可以使用TODO highlight或TODO Tree等 IDE 扩展程序，直接在 IDE 中显示和跟踪剩余的错误。

🚀 结论

从一开始就强制执行 ESLint 规则是打造卓越代码库的关键一步。通过运用本文讨论的策略，您可以构建更简洁、更易于维护的代码库。

但旅程并未就此结束。如果您有任何疑问或想分享您的经验，请随时通过X/Twitter或GitHub联系我们。