为什么husky哈士奇放弃了传统的 JS 配置（翻译）

关于我最喜欢的哈士奇新功能以及导致它的原因的简短说明。

背景

我在 husky 上工作了 7 年，解决了 600 个与 JavaScript 项目中的 Git hooks 相关的问题。 1 月份，大约 100 个问题与新版本一起关闭。

从 v0 开始，husky 使用 JavaScript 配置 Git 挂钩，可以使用 .huskyrc.js 文件或 package.json 中的字段。

现在 Git 钩子是使用 .husky/ 目录中的钩子的单个文件配置的。

为什么突然改变？

一切都在变化和发展。 JS 生态系统已经发生了变化（yarn 已经被引入，monorepos 成为一种趋势，新工具和最佳实践出现了，甚至 npm 的工作方式也略有不同……）并且 Git 引入了一个令人兴奋的新功能。

但在谈论新配置及其好处之前，让我们先看看 husky 到目前为止所采取的方法。

哈士奇是如何工作的

以一种非常 Linux 的方式，要配置 Git 挂钩，您只需将可执行文本文件放在 .git/hooks/ 中。

为了能够运行用户在 .huskyrc.js 中创建的任何 Git 钩子，husky 将所有可能的钩子安装在.git/hooks/中。

例如，当提交时，每个 Git 钩子都会检查 .huskyrc.js 中是否有相应的钩子定义：

$ git commitpre-commit (native) → husky/runner.js (node)→ is a pre-commit defined in `.huskyrc.js`? → YES, run itprepare-commit-msg (native) → husky/runner.js (node)→ is a prepare-commit-msg defined in `.huskyrc.js`? → NO, do nothingcommit-msg (native) → husky/runner.js (node)→ is a commit-msg defined in `.huskyrc.js`? → NO, do nothingpost-commit (native) → husky/runner.js (node)→ is a post-commit defined in `.huskyrc.js`? → NO, do nothing

它的好处：用户可以从 .huskyrc.js 添加、更新和删除钩子，并且会自动选择更改。

不利的一面是，即使没有任何东西可以运行，node也会启动。

但是你可能会问，我们不能只安装所需的钩子吗？这是三年前设想的（#260），但哈士奇不再“自动工作”了。

例如，让我们考虑以下配置：

// .huskyrc.js
// .huskyrc.js
module.exports = {hooks: {'pre-commit': 'cmd'}
}

.git/hooks/pre-commit ← 以某种方式创建

然后你修改它：

// .huskyrc.js
// .huskyrc.js
module.exports = {hooks: {// 'pre-commit': 'cmd', ← removed'commit-msg': 'cmd'     ← added}
}

您的 .git/hooks 目录现在不一致：

.git/hooks/pre-commit ← 仍然存在
.git/hooks/commit-msg ← 不存在

由于你的钩子定义不再在一个地方，而是在两个地方（.huskyrc.js 和 .git/hooks/），突然你需要样板来保持 JS 世界与 Git 世界同步。

每次 .huskyrc.js 发生变化时，您（和您的合作者）都需要重新生成钩子。重新生成可能与某些事件绑定，但没有可靠的方法来涵盖所有可能的情况，并且会出现意外行为。这就是为什么这种方法被驳回的原因。

哈士奇新方法

当你的抽象有缺陷时，通常是退步的信号。

到目前为止，我们知道什么？

按照设计，Git 挂钩配置是通过可执行脚本完成的。
哈士奇最初的方法是一种间接的方法和一点魔法。
从 JS 配置生成 Git 钩子可能会不同步。

我们可以用 Git 做得更好吗？

2016 年，Git 2.9 引入了 core.hooksPath。它让你告诉 Git 不要使用 .git/hooks/ 而是另一个目录。

这就是新哈士奇的基础：

husky install 命令告诉 Git 使用 .husky/ 作为 Git hooks 目录。
husky add 创建一个带有小包装器的独立 shell 脚本来支持一些附加功能。
它解决了第一个问题（不必要的 Git 挂钩）和第二个问题（将挂钩定义放在单独一个地方）。

换句话说，当你用新的 husky 创建一个 hook 时，它是纯 shell 并且可以直接访问。 Git 和你之间再也没有什么了❤️。我觉得很漂亮。

但…

“有目录并不常见。”

这取决于，其他工具使用目录来存储配置。例如，一个 repo 可以有以下目录 .vscode/, .github/, .storybook/, …

从技术上讲，它只是树层次结构中的另一个条目。 .husky/ 目录不会比 .huskyrc.js 文件增加更多的视觉混乱。

这也是 Git 钩子的设计方式，也是 husky 遵循这种方法的原因。

但是，您可以选择放置 .husky/ 的位置。例如，它可以在 config/ 中与其他配置文件分组，供那些愿意的人使用。

“像 Jest、ESLint、Prettier 等 JS 工具都是用 JS config 配置的，husky 是一个 JS 工具。”

你可以拥有 .jestrc.js、.eslintrc.js、.prettierrc.js，这是有道理的，因为它们完全是用 JS 编写的。

但是 husky 是个特例，它不是纯 JS，它是“混合”的。它与已经可以配置的非 JS 工具交互。

“设置起来更难。”

Husky 带有一个init命令（推荐），你可以在几秒钟内完成。

$ npx @husky/init # 完成！

也就是说，手动设置 husky 只需要完成一次。您必须更改 package.json 中的一行并运行一个命令来添加一个钩子（仅此而已）。

这与 jest、eslint的步骤数相同……将命令添加到 package.json 并创建一个文件 .jestrc.js、.eslintrc.js、……

（不过只有一个例外，如果您要发布一个包并同时使用 Yarn v2，则需要三行）

“如果有 core.hooksPath，为什么还要使用 husky？”

Husky 提供了一些基于以前版本反馈的安全防护、用户友好的错误消息和一些附加功能。这是完全原生和一点用户友好性之间的平衡。

“迁移会很复杂。”

有 husky-4-to-6 CLI 会自动为您完成。

…但我仍然想在 package.json 中定义钩子

好消息！没有什么能阻止你这样做