前端实用工具（二）：编程规范化办理方案

目录
本地代码规范化工具
代码检测工具ESLint
代码格式化工具Prettier
远程代码规范化工具
远程提交规范化工具commitizen
提交规范检验工具commitlint +husky
什么是git hooks
commitlint安装
husky安装
检测代码提交规范 ESLint +husky
主动修复格式错误lint-staged

---

本地代码规范化工具

代码检测工具ESLint

项目中的.eslintrc.js 文件

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

复制代码

之后ESLint规则在rules中以键值对的情势添加

代码格式化工具Prettier

安装prettier插件
新建 .prettierrc 文件，该文件为 perttier 默认配置文件

1. {
2.   // 不尾随分号
3.   "semi": false,
4.   // 使用单引号
5.   "singleQuote": true,
6.   // 多行逗号分割的语法中，最后一行不加逗号
7.   "trailingComma": "none"
8. }

复制代码

在VSCode设置中，搜刮 save ，勾选 Format On Save

ESLint和prettier的常见标题？
● VSCode默认制表符是4个空格，而ESLint希望一个制表符是两个空格
● 假如VSCode安装多个代码格式化工具大概会冲突
● ESLint和Prettier之间有冲突，默认ESLint括号前会有空格需要手动关闭'space-before-function-paren':'off'

远程代码规范化工具

远程提交规范化工具commitizen

commitizen 仓库名为 cz-cli ，它提供了一个 git cz 的指令用于代替 git commit，简朴一句话介绍它：
当你使用 commitizen 进行代码提交（git commit）时，commitizen 会提交你在提交时填写所有必须的提交字段！

commitizen安装步调如下：

• 全局安装Commitizen
  

1. npm install -g commitizen@4.2.4

复制代码

• 安装并配置 cz-customizable 插件
  

• 使用 npm 下载 cz-customizable
  

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

复制代码

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

1. ...
2.   "config": {
3.     "commitizen": {
4.       "path": "node_modules/cz-customizable"
5.     }
6.   }

复制代码

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

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

复制代码

• 使用 git cz 代替 git commit
  

补充：
不同的团队大概会有不同的标准，那么咱们今天就以目前使用较多的 Angular团队规范 延伸出的 Conventional Commits specification（约定式提交） 为例，来为大家详解 git 提交规范
约定式提交规范要求如下：

1. <type>[optional scope]: <description>
3. [optional body]
5. [optional footer(s)]
7. --------  翻译 -------------
8.    
9. <类型>[可选 范围]: <描述>
11. [可选 正文]
13. [可选 脚注]

复制代码

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

• 新功能：feat
  
• 修复：fix
  
• 文档变更：docs
  
• ....
  

假如忘记了git cz指令，我们有没有方法限定这种错误的出现？
我们可以使用git hooks + commitlint阻止不规范提交
提交规范检验工具commitlint +husky

检查提交形貌是否符合规范要求husky+commitlint
什么是git hooks

Git hooks(git 钩子 || git 回调方法)：git在执行某些事件之间或之后进行一些其他额外的操纵

PS：详细的 HOOKS介绍 可点击这里查看
整体的 hooks 非常多，当时我们其中用的比力多的其实只有两个：

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

• Husky：主要作用是简化git hooks的配置和管理，可以通过配置文件定义钩子行为（简化拆分git hooks）
  
• commitlint：用来检查提交信息
  

Husky 和 commitlint 通常一起使用，Husky监听commit-msg函数，在每次提交之前触发commitlint 检查提交规范

下面我们分别安装两个工具
commitlint安装

• 安装依靠：
  

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

复制代码

• 创建 commitlint.config.js 文件（也可以手动创建）
  

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

复制代码

• 打开 commitlint.config.js ， 增加配置项（ config-conventional 默认配置点击可查看 ）：
  

1. module.exports = {
2.   // 继承的规则
3.   extends: ['@commitlint/config-conventional'],
4.   // 定义规则类型
5.   rules: {
6.     // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
7.     'type-enum': [
8.       // 当前验证的错误级别
9.       2,
10.       // 在什么情况下进行验证
11.       'always',
12.       [
13.         'feat', // 新功能 feature
14.         'fix', // 修复 bug
15.         'docs', // 文档注释
16.         'style', // 代码格式(不影响代码运行的变动)
17.         'refactor', // 重构(既不增加新功能，也不是修复bug)
18.         'perf', // 性能优化
19.         'test', // 增加测试
20.         'chore', // 构建过程或辅助工具的变动
21.         'revert', // 回退
22.         'build' // 打包
23.       ]
24.     ],
25.     // subject 大小写不做校验
26.     'subject-case': [0]
27.   }
28. }

复制代码

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

husky安装

• 安装依靠：
  

1. npm install husky@7.0.1 --save-dev

复制代码

• 启动 hooks ， 天生 .husky 文件夹
  

1. npx husky install

复制代码

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

下令无效就手动添加

1. npm set-script prepare "husky install"

复制代码

• 执行 prepare 指令
  

1. npm run prepare

复制代码

• 执行乐成，提示
  

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

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

复制代码

• 此时的 .husky 的文件结构
  

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

1. PS F:\xxxxxxxxxxxxxxxxxxxxx\test-admin> git commit -m "测试"
2. ⧗   input: 测试
3. ✖   subject may not be empty [subject-empty]
4. ✖   type may not be empty [type-empty]
6. ✖   found 2 problems, 0 warnings
7. ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
9. husky - commit-msg hook exited with code 1 (error)

复制代码

检测代码提交规范 ESLint +husky

在前面的ESLint和Prettier配合办理的是本地代码的格式标题，而且我们需要手动在VSCode中配置主动保存
假如本地忘记配置了，怎么在提交之前如何检测代码格式是否错误？
husky 监测 pre-commit 钩子，在该钩子下执行 npx eslint --ext .js,.vue src 指令往复进行相关检测
执行脚本，在pre-commit中执行检测代码

1. npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src"

复制代码

操纵会天生对应文件 pre-commit：

此时假如不符合ESLint标准，代码提交失败

主动修复格式错误lint-staged

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

• 修改 package.json 配置
  

1. "lint-staged": {
2.     "src/**/*.{js,vue}": [
3.       "eslint --fix",
4.       "git add"
5.     ]
6.   }

复制代码

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

• 假如符合规则：则会提交乐成。
  
• 假如不符合规则：它会主动执行 eslint --fix 尝试帮你主动修复，假如修复乐成则会帮你把修复好的代码提交，假如失败，则会提示你错误，让你修睦这个错误之后才气答应你提交接码。
  

• 修改 .husky/pre-commit 文件
  

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

复制代码

• 再次执行提交接码
  
• 发现 暂存区中 不符合 ESlint 的内容，被主动修复
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。