深入哈士奇和林特舞台

上周我谈到了ESLint以及它在确保多位贡献者项目代码一致性方面的作用。如果你还没读过那篇文章，我建议你先阅读那篇文章再继续阅读本文。

今天，我们将重点介绍如何自动运行 ESLint，以确保项目的主分支始终遵循您特定的规则集。

棉絮状的

首先要介绍的工具是lint-staged。lint -staged需要在你的package.json文件中进行配置。

{
  "lint-staged": {
    "*.js": "eslint --fix"
  }
}

如上例所示，您可以使用 glob 模式来告诉 lint-staged 要检查哪些文件。此外，您还可以为 lint-staged 指定要对这些文件执行的命令。在许多情况下，您需要执行多个命令，lint-staged 也支持这样做。在本例中，您将运行 ESLint 和prettier。

{
  "lint-staged": {
    "*.js": ["eslint", "prettier --write"]
  }
}

那么 lint-staged 是如何工作的呢？它专门用于处理“暂存”文件，因此得名。这意味着您已经修改或创建了文件，但尚未提交到项目中。处理暂存文件可以限制您每次需要检查的文件数量，从而加快工作流程。您配置的命令会在“提交前”运行。当您尝试将文件提交到项目时，您会在终端中看到 ESLint 的运行。完成后，您可能已经成功提交，或者会发现一些需要修复的 lint 错误，然后才能提交代码。

然而，您可能没有意识到，lint-staged 并不是唯一在后台运行的工具。Lint-staged 的​​设计初衷是与另一个名为husky 的工具配合使用。

沙哑

你可能之前已经接触过 Husky，只是没有注意到。多年来，它都是通过 package.json 文件中的几行代码进行配置的。类似这样。

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },

然而，最新版本的 Husky v6 改变了这种方式。现在，Husky 使用不同的 Bash 文件，文件名与其对应的工作流程步骤相匹配，例如“pre-commit”。幸运的是，您无需自行设置，Husky 提供了一个便捷的命令行工具来帮您完成这些操作。

npx husky-init && npm install
npx husky add .husky/pre-commit "npm test"

该命令的第一行是一个一次性初始化脚本，确保所有同事在尝试提交文件之前，他们的机器上都已安装了 husky。

第二行代码会在目录pre-commit下创建文件.husky。查看该文件后，你会发现它会husky.sh在你初始化命令之前运行一个脚本。理论上可以删除这个脚本，但我建议保留它。该脚本允许执行一些操作，包括使用一个--no-verify标志来绕过检查。

初始化目录和关联文件后，就可以向其中添加任何你想要的命令。在我的例子中，我将其替换npm test为npm lint-staged。

预推

工作pre-commit流程大致符合理想状态。但是，如果你的项目不想在提交时进行代码检查，而是希望在开发人员尝试将更改推送到分支时进行检查，该怎么办？

虽然创建.husky/pre-push文件并运行 `lint-staged` 很诱人，但这行不通。Huskypre-push的工作流程是正确的，但此时运行 `lint-staged` 会返回 0 个匹配文件。这很合理，虽然确实让我困惑了一会儿，因为已提交的文件不再处于暂存状态。不过，您还有以下几种选择。

1. 对所有文件运行 ESLint：eslint '*.js'
2. 与以下情况的差异main：eslint --no-error-on-unmatched-pattern $(git diff main... --name-only --- '*.js')

请注意，这只是 diff 命令的一个示例，根据您的项目，还有许多其他需要考虑的因素。

后续步骤和持续集成

在 Git 工作流程中运行 ESLint、Prettier 甚至测试都很重要，因为它能帮助你快速发现问题并排查错误。但是，它并不能替代持续集成 (CI) 检查。通常，你需要在两个环境中都运行这些命令，以确保没有任何遗漏。

但总的来说，这些工具有助于确保生产代码库更简洁、更一致。从长远来看，这对任何项目来说都是一大优势。