项目开启

1.ESLint

ESLint官网请点击我

ESLint 是 2013年6月 创建的一个开源项目，它的目标非常简单，只有一个，那就是 提供一个插件化的 javascript 代码检测工具 ，说白了就是做 代码格式检测使用的

• 项目中都会带有.eslintrc.js文件,这个文件就是eslint的配置文件
• eslint在公司中渐渐的被重视起来
• 在创建项目的时候会有以下配置选项

  Pick a linter / formatter config: 
  ESLint with error prevention only // 仅包含错误的 ESLint
  ESLint + Airbnb config // Airbnb 的 ESLint 延伸规则
  ESLint + Standard config // 标准的 ESLint 规则

[注意]  在这个项目中使用的是标准的eslint规则,打开项目会发现有一个.eslintrc.js文件，配置如下

 module.exports = {
   root: true,
   env: {
     node: true
   },
   extends: [
     'plugin:vue/vue3-essential',
     '@vue/standard'
   ],
   parserOptions: {
     parser: '@babel/eslint-parser'
   },
   rules: {
     'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
     'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off'
   }
 }
 ​

• root表示当前目录即为根目录,Eslint规则会被限制🚫在该目录下
• env表示启用eslint检测环境
• node为true代表在node环境下启用eslint检测
• extedns是指基础配置需要继承的配置
• parserOptions代表解析器
• rules见名之意就是规则，解释如下

错误级别分为三种：

"off" 或 0 - 关闭规则

"warn" 或 1 - 开启规则，使用警告级别的错误：warn (不会导致程序退出)

"error" 或 2 - 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)

---

2.Prettier

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

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

1. 打开 .eslintrc.js 配置文件
2. 在 rules 规则下，新增一条规则

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

1. 重启项目

---

3.约定式提交规范

• 在项目开发过程中,都会使用git进行项目管理,只要通过git就会遇到提交代码的场景

• 那么如果在执行 git commit -m "描述信息",这个描述信息怎么进行规定呢,如果瞎写会对其他人阅读不友好,也不知道你干了啥,来看看下面这几条例子

  

这么看起来会很懵逼,这啥玩意。

• 所以git提交规范必须执行
• 但是这个标准是什么呢,这里采用目前使用较多的Angular团队规范 衍生出的延伸出的 Conventional Commits specification（约定式提交） 为例

规则如下

 <type>[optional scope]: <description>
 ​
 [optional body]
 ​
 [optional footer(s)]
 ​
 --------  翻译 -------------
     
 <类型>[可选 范围]: <描述>
 ​
 [可选 正文]
 ​
 [可选 脚注]

在其中类型是一个可选值,比如:

新功能：feat

修复：fix

文档变更：docs

Etc....

那么意思就是说如果按照约定式提交规范进行的话,岂不是累死,那么我宁愿瞎写,如何优化呢?

这时候就需要使用到git 提交规范化工具的东西

• 这里有一个叫做commitizen就提供了git cz的指令用于代替git commit
• 它会帮助填写所有必须的提交字段
• 如何使用呢？

1. 首先需要安装

 npm install -g commitizen

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

   1. 使用 npm 下载 cz-customizable

    npm i cz-customizable --save-dev
   

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

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

2. 项目根目录下创建 .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
 }

1. 使用 git cz 代替 git commit就可以代替git commit

---

4.Git Hooks

如果本来是使用git cz来提交代码,但还是习惯使用了git commit怎么办

怎么做？

当提交只要不符合约定式提交规范的时候,就阻止当前的提交,并且提示错误

如果要实现这个目的,就需要先来了解一个概念,叫做Git hooks

就是git 执行某个时间之前或者之后进行一些其他额外的操作

下面是一些hoooks

Git Hook	调用时机	说明
pre-applypatch	git am执行前
applypatch-msg	git am执行前
post-applypatch	git am执行后	不影响git am的结果
pre-commit	git commit执行前	可以用git commit --no-verify绕过
commit-msg	git commit执行前	可以用git commit --no-verify绕过
post-commit	git commit执行后	不影响git commit的结果
pre-merge-commit	git merge执行前	可以用git merge --no-verify绕过。
prepare-commit-msg	git commit执行后，编辑器打开之前
pre-rebase	git rebase执行前
post-checkout	git checkout或git switch执行后	如果不使用--no-checkout参数，则在git clone之后也会执行。
post-merge	git commit执行后	在执行git pull时也会被调用
pre-push	git push执行前
pre-receive	git-receive-pack执行前
update
post-receive	git-receive-pack执行后	不影响git-receive-pack的结果
post-update	当 git-receive-pack对 git push 作出反应并更新仓库中的引用时
push-to-checkout	当`git-receive-pack对git push做出反应并更新仓库中的引用时，以及当推送试图更新当前被签出的分支且receive.denyCurrentBranch配置被设置为updateInstead时
pre-auto-gc	git gc --auto执行前
post-rewrite	执行git commit --amend或git rebase时
sendemail-validate	git send-email执行前
fsmonitor-watchman	配置core.fsmonitor被设置为.git/hooks/fsmonitor-watchman或.git/hooks/fsmonitor-watchmanv2时
p4-pre-submit	git-p4 submit执行前	可以用git-p4 submit --no-verify绕过
p4-prepare-changelist	git-p4 submit执行后，编辑器启动前	可以用git-p4 submit --no-verify绕过
p4-changelist	git-p4 submit执行并编辑完changelist message后	可以用git-p4 submit --no-verify绕过
p4-post-changelist	git-p4 submit执行后
post-index-change	索引被写入到read-cache.c do_write_locked_index后

PS：详细的 HOOKS介绍 可点击这里查看

整体的 hooks 非常多，当时我们其中用的比较多的其实只有两个：

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

简单来说这两个钩子：

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

而我们接下来要做的关键，就在这两个钩子上面。

---

5.husky + commitlint

如果要使用git hooks来校验提交信息,就要使用以下工具

1. commitlint：用于检查提交信息
2. husky：是git hooks工具

1. commitlint

安装依赖:

 npm install --save-dev @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4

创建 commitlint.config.js 文件

 echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

打开 commitlint.config.js ， 增加配置项（ 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 的编码格式**，否则可能会出现以下错误：

1. husky

安装依赖：

 npm install husky@7.0.1 --save-dev

启动 hooks ， 生成 .husky 文件夹

 npx husky install

在 package.json 中生成 prepare 指令

 npm set-script prepare "husky install"

执行 prepare 指令

 npm run prepare

执行成功，提示

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

 npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

此时的 .husky 的文件结构

至此， 不符合规范的 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)

---

6.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：

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 检测到了代码的提交规范问题。

7：lint-staged 自动修复格式错误

在第7点中通过 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 文件

    #!/bin/sh
    . "$(dirname "$0")/_/husky.sh"
    ​
    npx lint-staged
    ​
   

4. 再次执行提交代码

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

8：总结

本节就可以总体分为两大类：

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：只检查本次修改更新的代码，并在出现错误的时候，自动修复并且送,总结就是如果你配置好,只要git提交就会进行验证,如果能进行修改那么就会通过我们配置过的规则进行修改