手把手带你从零到一实现标准化大厂编程规范解决方案之ESLint + Prettier + Git Hooks

默海笑
116 阅读14分钟

1、为什么需要编程规范？

工欲善其事，必先利其器

对于一些大型的企业级项目而言，通常情况下我们都是需要一个团队来进行开发的。而又因为团队人员对技术理解上的参差不齐，所以就会导致出现一种情况，那就是《一个项目无法具备统一的编程规范，导致项目的代码像多个不同材质的补丁拼接起来一样》

海笑我就不和多啰嗦了直接上干货。本次我们需要使用的规范三件套 ESLint + Prettier + Git Hooks

下面我会手动的启动一个项目手把手带你做一套大厂味道的代码规范。

初始化项目

我们使用的是vue项目作为讲解，使用脚手架直接一步到位。

首先根据官网初始化项目。cn.vuejs.org/guide/quick…

我下面红色选择的都是需要安装的

image.png

安装好之后，执行下面的代码就可以运行项目了。

cd <your-project-name> 
$ npm install 
$ npm run dev

浅浅玩弄一下 ESLint

打开项目中的 eslint.config.js 文件

import js from '@eslint/js'
import pluginVue from 'eslint-plugin-vue'
import skipFormatting from '@vue/eslint-config-prettier/skip-formatting'

export default [
  {
    name: 'app/files-to-lint',
    files: ['**/*.{js,mjs,jsx,vue}'],
  },

  {
    name: 'app/files-to-ignore',
    ignores: ['**/dist/**', '**/dist-ssr/**', '**/coverage/**'],
  },

  js.configs.recommended,
  ...pluginVue.configs['flat/essential'],
  skipFormatting,
  customRules, // 添加自定义规则配置
]

初始化是上面这个样子的，我们可以将想要的代码规范设置到里面。

// 自定义的规则配置
const customRules = {
  quotes: 'error', // 默认
  // 表示当前目录即为根目录，ESLint 规则将被限制到该目录下
  root: true,
  // env 表示启用 ESLint 检测的环境
  env: {
    // 在 node 环境下启动 ESLint 检测
    node: true,
  },
  // ESLint 中基础配置需要继承的配置
  extends: ['plugin:vue/vue3-essential', '@vue/standard'],
  // 解析器
  parserOptions: {
    parser: 'babel-eslint',
  },
  // 需要修改的启用规则及其各自的错误级别
  /**
   * 错误级别分为三种：
   * "off" 或 0 - 关闭规则
   * "warn" 或 1 - 开启规则，使用警告级别的错误：warn (不会导致程序退出)
   * "error" 或 2 - 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)
   */
  rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
  },
}

export default [
  ...,
  customRules, // 添加自定义规则配置
]

这样我们就实现了自己想要的效果。

比如：

我们可以把 Home.vue 中的 name 属性值，由单引号改为双引号

此时，只要我们一保存代码，那么就会得到一个对应的错误

image-20210904185336318.png

这个错误表示：

  1. 此时我们触发了一个 《错误级别的错误》
  2. 触发该错误的位置是 在 Home.vue 的第 13 行 第九列 中
  3. 错误描述为：字符串必须使用单引号
  4. 错误规则为：quotes

当然你也可以在文件夹下面创建一个.eslintrc.js文件进行一个规范的编写。

// ESLint 配置文件遵循 commonJS 的导出规则，所导出的对象就是 ESLint 的配置对象
// 文档：https://eslint.bootcss.com/docs/user-guide/configuring
module.exports = {
  // 表示当前目录即为根目录，ESLint 规则将被限制到该目录下
  root: true,
  // env 表示启用 ESLint 检测的环境
  env: {
    // 在 node 环境下启动 ESLint 检测
    node: true
  },
  // ESLint 中基础配置需要继承的配置
  extends: ["plugin:vue/vue3-essential", "@vue/standard"],
  // 解析器
  parserOptions: {
    parser: "babel-eslint"
  },
  // 需要修改的启用规则及其各自的错误级别
  /**
   * 错误级别分为三种：
   * "off" 或 0 - 关闭规则
   * "warn" 或 1 - 开启规则，使用警告级别的错误：warn (不会导致程序退出)
   * "error" 或 2 - 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)
   */
  rules: {
    "no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
    "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off"
  }
};

该宠幸 Prettier 了

昨天晚上是eslint伴我入睡，今天该Prettier了。

prettier` 是什么？

  1. 一个代码格式化工具
  2. 开箱即用
  3. 可以直接集成到 VSCode 之中
  4. 在保存时，让代码直接符合 ESLint 标准（需要通过一些简单配置）

首先得动一下vscode

  1. 在 VSCode 中安装 prettier 插件（搜索 prettier），这个插件可以帮助我们在配置 prettier 的时候获得提示

image-20210904195026475.png

  1. 在项目中新建 .prettierrc 文件，该文件为 perttier 默认配置文件

  2. 在该文件中写入如下配置：

{
  // 不尾随分号
  "semi": false,
  // 使用单引号
  "singleQuote": true,
  // 多行逗号分割的语法中，最后一行不加逗号
  "trailingComma": "none"
}

image.png

我们尝试在 Home.vue 中写入一个 created 方法，写入完成之后，打开我们的控制台我们会发现，此时代码抛出了一个 ESLint 的错误 image-20210904201057594.png

这个错误的意思是说：created 这个方法名和后面的小括号之间，应该有一个空格！

但是当我们加入了这个空格之后，只要一保存代码，就会发现 prettier 会自动帮助我们去除掉这个空格。

那么此时的这个问题就是 prettier 和 ESLint 的冲突问题。

针对于这个问题我们想要解决也非常简单：

  1. 打开 .eslintrc.js 配置文件

  2. 在 rules 规则下，新增一条规则

'space-before-function-paren': 'off'

  1. 该规则表示关闭《方法名后增加空格》的规则

  2. 重启项目

至此我们整个的 perttier 和 ESLint 的配合使用就算是全部完成了。

在之后我们写代码的过程中，只需要保存代码，那么 perttier 就会帮助我们自动格式化代码，使其符合 ESLint 的校验规则。而无需我们手动进行更改了。

我的老情人 Git

老实说，工作中没她还真不行。

除了 代码格式规范 之外，还有另外一个很重要的规范就是 git 提交规范！

在现在的项目开发中，通常情况下，我们都会通过 git 来管理项目。只要通过 git 来管理项目，那么就必然会遇到使用 git 提交代码的场景。

约定式提交规范要求如下：

js
 代码解读
复制代码
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

--------  翻译 -------------
    
<类型>[可选 范围]: <描述>

[可选 正文]

[可选 脚注]

其中 <type> 类型，必须是一个可选的值，比如：

  1. 新功能：feat
  2. 修复：fix
  3. 文档变更：docs
  4. ....

也就是说，如果要按照 约定式提交规范 来去做的化，那么你的一次提交描述应该式这个样子的：

image-20210904205519762.png

我想大家看到这样的一个提交描述之后，心里的感觉应该和我一样是崩溃的！要是每次都这么写，写到猴年马月了！

经过了很多人的冥思苦想，就出现了一种叫做 git 提交规范化工具 的东西，而我们要学习的 commitizen 就是其中的佼佼者！

commitizen 仓库名为 cz-cli ，它提供了一个 git cz 的指令用于代替 git commit，简单一句话介绍它：

当你使用 commitizen 进行代码提交（git commit）时，commitizen 会提交你在提交时填写所有必需的提交字段！

这句话怎么解释呢？不用着急，下面我们就来安装并且使用一下 commitizen ，使用完成之后你自然就明白了这句话的意思！

  1. 全局安装Commitizen

    npm install -g commitizen@4.2.4

  2. 安装并配置 cz-customizable 插件

    1. 使用 npm 下载 cz-customizable

      npm i cz-customizable@6.3.0 --save-dev

    2. 添加以下配置到 package.json 中

      ...
  "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"
    }
  }

  3. 项目根目录下创建 .cz-config.js 自定义提示文件

    module.exports = {
  // 可选类型
  types: [
    { value: 'feat', name: 'feat:     新功能' },
    { value: 'fix', name: 'fix:      修复' },
    { value: 'docs', name: 'docs:     文档变更' },
    { value: 'style', name: 'style:    代码格式(不影响代码运行的变动)' },
    {
      value: 'refactor',
      name: 'refactor: 重构(既不是增加feature，也不是修复bug)'
    },
    { value: 'perf', name: 'perf:     性能优化' },
    { value: 'test', name: 'test:     增加测试' },
    { value: 'chore', name: 'chore:    构建过程或辅助工具的变动' },
    { value: 'revert', name: 'revert:   回退' },
    { value: 'build', name: 'build:    打包' }
  ],
  // 消息步骤
  messages: {
    type: '请选择提交类型:',
    customScope: '请输入修改范围(可选):',
    subject: '请简要描述提交(必填):',
    body: '请输入详细描述(可选):',
    footer: '请输入要关闭的issue(可选):',
    confirmCommit: '确认使用以上信息提交？(y/n/e/h)'
  },
  // 跳过问题
  skipQuestions: ['body', 'footer'],
  // subject文字长度默认是72
  subjectLimit: 72
}

  4. 使用 git cz 代替 git commit 使用 git cz 代替 git commit，即可看到提示内容

那么到这里我们就已经可以使用git cz 来代替了 git commit 实现了规范化的提交诉求了，但是当前依然存在着一个问题，那就是我们必须要通过 git cz 指令才可以完成规范化提交！

那么如果有马虎的同事，它们忘记了使用 git cz 指令，直接就提交了怎么办呢？

那么有没有方式来限制这种错误的出现呢？ 那么就需要引出git hooks这个概念了

通过 git hooks 使用 husky + commitlint 检查提交描述是否符合规范要求

git hooks 也就是 git 在执行某个事件之前或之后进行一些其他额外的操作

而我们所期望的 阻止不合规的提交消息，那么就需要使用到 hooks 的钩子函数。

下面是官网 git-scm.com/docs/githoo…

这里我们主要是使用2个hooks

Git Hook调用时机说明
pre-commitgit commit执行前 它不接受任何参数，并且在获取提交日志消息并进行提交之前被调用。脚本git commit以非零状态退出会导致命令在创建提交之前中止。可以用git commit --no-verify绕过
commit-msggit commit执行前 可用于将消息规范化为某种项目标准格式。 还可用于在检查消息文件后拒绝提交。可以用git commit --no-verify绕过

简单来说这两个钩子：

  1. commit-msg：可以用来规范化标准格式，并且可以按需指定是否要拒绝本次提交
  2. pre-commit：会在提交前被调用，并且可以按需指定是否要拒绝本次提交

注意：npm 需要在 7.x 以上版本！！！！！

那么下面我们分别来去安装一下这两个工具：

commitlint

  1. 安装依赖：
npm install --save-dev @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4
  1. 创建 commitlint.config.cjs 文件 cjs不使用js是模块的问题
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.cjs
  1. 打开 commitlint.config.cjs ，增加配置项 config-conventional 默认配置点击可查看
module.exports = {
  // 继承的规则
  extends: ['@commitlint/config-conventional'],
  // 定义规则类型
  rules: {
    // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
    'type-enum': [
      2,
      'always',
      [
        'feat', // 新功能 feature
        'fix', // 修复 bug
        'docs', // 文档注释
        'style', // 代码格式(不影响代码运行的变动)
        'refactor', // 重构(既不增加新功能，也不是修复bug)
        'perf', // 性能优化
        'test', // 增加测试
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回退
        'build' // 打包
      ]
    ],
    // subject 大小写不做校验
    'subject-case': [0]
  }
}

注意：确保保存为 UTF-8 的编码格式，否则可能会出现以下错误：

image-20210710121456416.png

接下来我们来安装 husky

husky

  1. 安装依赖：

    npm install husky@7.0.1 --save-dev

  2. 启动 hooks ， 生成 .husky 文件夹

    npx husky install

image-20210906202034156.png

  1. 在 package.json 中生成 prepare 指令（ 需要 npm > 7.0 版本 ）

    arduino
 代码解读
复制代码
npm set-script prepare "husky install"

image-20210906202128323.png

  1. 执行 prepare 指令

    arduino
 代码解读
复制代码
npm run prepare

  2. 执行成功，提示

image-20210710120053221.png

  1. 添加 commitlint 的 hook 到 husky中，并指令在 commit-msg 的 hooks 下执行 npx --no-install commitlint --edit "$1" 指令

    sql
 代码解读
复制代码
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

  2. 此时的 .husky 的文件结构

image-20210710120228931.png

至此， 不符合规范的 commit 将不再可提交：

PS F:\xxxxxxxxxxxxxxxxxxxxx\imooc-admin> git commit -m "测试"
⧗   input: 测试
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky - commit-msg hook exited with code 1 (error)

image.png

那么至此，我们就已经可以处理好了 强制规范化的提交要求，到现在 不符合规范的提交信息，将不可在被提交！

那么到这里我们的 规范化目标 就完成了吗？

当然没有！

现在我们还缺少一个 规范化的处理 ，那就是 代码格式提交规范处理！

有同学看到这里可能说，咦！ 这个怎么看着这么眼熟啊？这个事情我们之前不是做过了吗？还需要在处理什么？

通过 pre-commit 检测提交时代码规范

在 ESLint 与 Prettier 配合解决代码格式问题 的章节中，我们讲解了如何处理 本地！代码格式问题。

但是这样的一个格式处理问题，他只能够在本地进行处理，并且我们还需要 手动在 VSCode 中配置自动保存 才可以。那么这样就会存在一个问题，要是有人忘记配置这个东西了怎么办呢？他把代码写的乱七八糟的直接就提交了怎么办呢？

所以我们就需要有一种方式来规避这种风险。

那么想要完成这么一个操作就需要使用 husky 配合 eslint 才可以实现。

我们期望通过 husky 监测 pre-commit 钩子，在该钩子下执行 npx eslint --ext .js,.vue src 指令来去进行相关检测：

  1. 执行 npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src" 添加 commit 时的 hook （npx eslint --ext .js,.vue src 会在执行到该 hook 时运行）
  2. 该操作会生成对应文件 pre-commit：

image-20210906204043915.png

  1. 关闭 VSCode 的自动保存操作

  2. 修改一处代码，使其不符合 ESLint 校验规则

  3. 执行 提交操作 会发现，抛出一系列的错误，代码无法提交

    PS F:\xxxxxxxxxxxxxxxxxxx\imooc-admin> git commit -m 'test'

F:\xxxxxxxxxxxxxxxx\imooc-admin\src\views\Home.vue
  13:9  error  Strings must use singlequote  quotes

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

husky - pre-commit hook exited with code 1 (error)

  4. 想要提交代码，必须处理完成所有的错误信息

那么到这里位置，我们已经通过 pre-commit 检测到了代码的提交规范问题。

那么到这里就万事大吉了吗？

在这个世界上从来不缺的就是懒人，错误的代码格式可能会抛出很多的 ESLint 错误，让人看得头皮发麻。严重影响程序猿的幸福指数。

那么有没有办法，让程序猿在 0 配置的前提下，哪怕代码格式再乱，也可以 ”自动“ 帮助他修复对应的问题，并且完成提交呢？

你别说，还真有！

那么咱们来看下一节《lint-staged 自动修复格式错误》

lint-staged 自动修复格式错误

pre-commit 处理了 检测代码的提交规范问题，当我们进行代码提交时，会检测所有的代码格式规范 。

但是这样会存在两个问题：

  1. 我们只修改了个别的文件，没有必要检测所有的文件代码格式
  2. 它只能给我们提示出对应的错误，我们还需要手动的进行代码修改

那么这一小节，我们就需要处理这两个问题

那么想要处理这两个问题，就需要使用另外一个插件 lint-staged ！

lint-staged 可以让你当前的代码检查 只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送

lint-staged 无需单独安装，我们生成项目时，vue-cli 已经帮助我们安装过了，所以我们直接使用就可以了

  1. 修改 package.json 配置

     代码解读
复制代码
"lint-staged": {
    "src/**/*.{js,vue}": [
      "eslint --fix",
      "git add"
    ]
  }

  2. 如上配置，每次它只会在你本地 commit 之前，校验你提交的内容是否符合你本地配置的 eslint规则(这个见文档 ESLint )，校验会出现两种结果：

    1. 如果符合规则：则会提交成功。
    2. 如果不符合规则：它会自动执行 eslint --fix 尝试帮你自动修复，如果修复成功则会帮你把修复好的代码提交，如果失败，则会提示你错误，让你修好这个错误之后才能允许你提交代码。

  3. 修改 .husky/pre-commit 文件

    js
 代码解读
复制代码
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

  4. 再次执行提交代码

  5. 发现 暂存区中 不符合 ESlint 的内容，被自动修复

最后总结

我们处理了 编程格式规范的问题，整个规范大体可以分为两大类：

  1. 代码格式规范
  2. git 提交规范

代码格式规范：

对于 代码格式规范 而言，我们通过 ESLint + Prettier + VSCode 配置 配合进行了处理。

最终达到了在保存代码时，自动规范化代码格式的目的。

git 提交规范：

对于 git 提交规范 而言我们使用了 husky 来监测 Git hooks 钩子，并且通过以下插件完成了对应的配置：

  1. 约定式提交规范
  2. commitizen：git 提交规范化工具
  3. commitlint：用于检查提交信息
  4. pre-commit： git hooks 钩子
  5. lint-staged：只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送
avatar
文章
阅读
粉丝