husky 和 lint-staged 构建代码项目规范

前言

最简单的方法

过 scripts 来解决如果检测工具多，需要多次处理

通过 husky(哈士奇)来解决容易遗忘的问题

1. 安装

2. husky init

3. 试一试

lint-stadge 只 lint 改动的

1. 安装

2. 修改 package.json 配置

3. 添加 npm 脚本:

4.使用 Husky 触发 lint-staged:

参考配置

总结

附：npx 查找规则

前言

一个项目如果涉及到多人协作，由于每个人代码的书写习惯和风格不太一样，如果没有统一的规范，那就会很乱，这对代码的可维护性大大降低。

所以现代工程有个一环节就是代码风格检查(Code Linting，下面以 Lint 简称)，来保障代码规范一致性

现在也有很多保障代码规范一致性，比如：ESLint、prettier、SCSSLint、JSONLint 等。比较全的可以见 github 官方的 Lint 工具列表[1]

本文不会介绍每一个工具怎么用，而是介绍怎么把这些工具串起来，构建一个代码检查的工作流。

最简单的方法

最简单的方法就是自己每次在 commit 代码之前先处理一下，以 eslint 举例：

eslint src/**/*.js

git add .

git commit -m 'feat: 一个新 feature'

这种方法有两个致命的缺点：

如果检测工具多，需要多次处理。
很容易遗忘。

过 scripts 来解决如果检测工具多，需要多次处理

scripts 就是 package.json 里的 scripts。

比如你同时需要用到 prettier 和 eslint，可以定制一个脚本，然后运行这个脚本之后再提交代码：

{
  "scripts": {
     "lint": "prettier --write & eslint src/**/*.js"
  }
}

然后每次提交代码前就只需要：

pm run lint

git add .

git commit -m 'feat: 一个新 feature'

通过 husky(哈士奇)来解决容易遗忘的问题

虽然咱们通过 scripts 来解决检查工具多的问题，但是还有一个容易遗忘怎么解呢？

解决方案就是通过 husky，原理实际上是通过 git hooks[2] 来解决，husky 就是让 git hooks 用起来更容易的工具。

“You can use it to lint your commit messages , run tests , lint code , etc... when you commit or push. Husky supports all Git hooks[3].”

这个是 husky 官网的一句话，用来描述 husky 可以做什么。

那到底怎么解决呢？接下来介绍一下 husky 的使用方式：

1. 安装

安装 husky

npm install --save-dev husky

`2. husky init`

husky init 推荐

init 命令简化了项目中的 husky 设置。它会在 .husky/ 中创建 pre-commit 脚本，并更新 package.json 中的 prepare 脚本。随后可根据你的工作流进行修改。

npx husky init

执行完之后文件根目录会多一个 .husky 文件夹：

3. 试一试

恭喜你！你已经成功地用一个命令设置了你的第一个 Git 钩子 🎉。让我们测试一下：

修改 .husky/pre-commit 文件
脚本会在每次提交时运行

pnpm lint

**问题：**默认进行的是全量检查，耗时问题，历史问题。

这个时候 commit 就会先自动执行 npm run lint 了，然后才会 commit。

但是这样解决了以上的问题，当项目大的时候会遇到一些问题，比如每次 lint 是整个项目的文件，文件太多导致跑的时间过久，另外如果这个 lint 是在项目后期接入的话，可能 lint 命令会报很多错误，全量去改可能会有问题。

lint-stadge 只 lint 改动的

基于上面的痛点，lint-stadge 就出现了，它的解决方案就是只检查本次提交所修改(指 git 暂存区[5]里的东西)的问题，这样每次 lint 量就比较小，而且是符合我们的需求的。

“如果不知道暂存区的需要去复习一下 git 知识，简单来说就是 git add 或者 git commit -a 的那部分代码会先放到暂存区。”

1. 安装

npm install -D lint-staged

2. 修改 package.json 配置

这段配置是 lint-staged 的配置项，它定义了当运行 lint-staged 时，对于特定文件类型应该执行哪些命令。下面是对这段配置的详细解释：

lint-staged: 这是 lint-staged 的配置对象，用于定义不同的文件模式和对应的命令。

"*.{js,ts,vue}": 这是一个 glob 模式，表示匹配所有扩展名为 .js、.ts 或 .vue 的文件。Glob 模式是一种文件路径模式，用于匹配文件系统中的文件名。

"eslint --fix": 这是一个命令，当 lint-staged 运行时，它会对所有匹配上述文件模式的文件执行这个命令。这里使用的是 ESLint，一个流行的 JavaScript 和 TypeScript 的代码质量和代码风格检查工具。

eslint 是命令本身，用于检查 JavaScript 或 TypeScript 代码中的问题。
--fix 是一个选项，它告诉 ESLint 尝试自动修复那些可以自动修复的问题。

当你在 Git 仓库中运行 git commit 命令时，如果 Husky 配置了 pre-commit 钩子来运行 lint-staged，那么 lint-staged 将会检查暂存区（staged）的文件。对于所有扩展名为 .js、.ts 或 .vue 的文件，它会执行 eslint --fix 命令。这将自动修复这些文件中的可修复问题，并将修复后的文件重新暂存，准备提交。

  "lint-staged": {
    "*.{js,ts,vue}": [
      "eslint --fix"
    ]
  }

3. 添加 npm 脚本:

在 package.json 中添加你需要的 npm 脚本，

  "scripts": {
    "lint-staged": "lint-staged"
  },

4.使用 Husky 触发 lint-staged:

在完成上面的配置之后，可以手动通过 npx lint-staged 来检查暂存区里面的文件。

手动是永远不会手动的，自动的方法就是将 npx lint-staged 设置到 hook 里。

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"


pnpm lint-staged

到现在我们的代码检查工作流就完成了。在 git commit 的时候就自动的回去帮我们跑检查脚本，而且还是只针对我们本次提交的代码进行检查。

参考配置

安装了插件 ESlint，开启保存自动修复
禁用了插件 Prettier，并关闭保存自动格式化

// ESlint插件 + Vscode配置 实现自动格式化修复
"editor.codeActionsOnSave": {
    "source.fixAll": true
},
"editor.formatOnSave": false,

.eslintrc 配置可以参考：

 rules: {
    'prettier/prettier': [
      'warn',
      {
        singleQuote: true, // 单引号
        semi: false, // 无分号
        printWidth: 80, // 每行宽度至多80字符
        trailingComma: 'none', // 不加对象|数组最后逗号
        endOfLine: 'auto' // 换行符号不限制（win mac 不一致）
      }
    ],
    // eslint 关注于规范，如果不符合规范报错
    'vue/multi-word-component-names': [
      'warn',
      {
        ignores: ['index'] // vue组件名称多单词组成（忽略index.vue）
      }
    ],
    'vue/no-setup-props-destructure': ['off'], // 关闭 props 解构的校验
    // 💡 添加未定义变量错误提示，create-vue@3.6.3 关闭，这里加上是为了支持下一个章节演示。
    'no-undef': 'error'
  }

总结

Husky 是一个用于管理 Git 钩子的工具，它可以让你在提交代码前自动运行脚本，比如代码格式化、代码检查等。它通过在 Git 仓库的 .husky 目录下创建钩子脚本来实现这个功能。

Husky使 Git hooks 变得简单https://typicode.github.io/husky/zh/

lint-staged 是一个运行在 Git 钩子上的 Node.js 脚本，它允许你使用 npm 脚本对暂存区的文件进行 lint 检查。它通常与 Husky 结合使用，以确保每次提交的代码都符合代码质量标准。

lint-staged - npmLint files staged by git. Latest version: 15.2.7, last published: a month ago. Start using lint-staged in your project by running `npm i lint-staged`. There are 2202 other projects in the npm registry using lint-staged.https://www.npmjs.com/package/lint-staged

使用 Husky 和 lint-staged 的好处是，它们可以帮助你自动化代码质量检查流程，确保每次提交的代码都符合团队的编码标准。这样不仅可以减少代码审查的工作量，还可以提高代码的整体质量

附：npx 查找规则

npx 是一个命令行工具，它随同 npm（Node Package Manager）一起提供，用于执行包中的程序。npx 允许你运行本地或全局安装的包中的命令，而无需单独安装每个包的可执行文件。

以下是 npx 的一些关键特性和查找规则：

执行本地或全局包：npx 首先检查当前项目中的 node_modules/.bin 目录，如果找到了要执行的命令，就会使用它。如果没有找到，它会尝试全局安装的包。
临时安装：如果你指定了一个包名但没有指定版本，npx 会临时安装该包的最新版本，然后执行它。
版本控制：如果指定了版本，npx 会根据版本号安装并执行正确的版本。
环境隔离：npx 会为每个执行创建一个干净的 node_modules 目录，这意味着不同的项目可以有不同的依赖版本，而不会相互干扰。
使用 npx 执行脚本：你可以使用 npx 来运行 package.json 中定义的脚本，例如 npx my-package start。
使用 npx 作为代理：你可以使用 npx 来代理全局安装的命令，例如 npx -p some-package some-command，这会先安装 some-package，然后执行 some-command。
查找规则：npx 首先在本地项目中查找命令，如果没有找到，它会在全局 node_modules 中查找。如果两者都没有找到，它会尝试从 npm 注册表下载并安装最新的包。
使用 --no-install：如果你不想让 npx 安装缺失的包，可以使用 --no-install 选项。
使用 --ignore-existing：如果你只想使用全局安装的包，可以使用 --ignore-existing 选项。
使用 --npm：如果你想要指定使用特定的 npm 版本，可以使用 --npm 选项。