大厂标准的编程规范

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

统一可维护

2.如何实现编程规范

让程序自动处理规范化内容
包括编程规范和git规范
ESLint 与 Prettier 配合解决代码格式问题

3.工具

eslint: 做代码格式检测使用的，当代码不符合ESLint格式会触发错误
prettier: 代码格式化工具,通过设置，保存时让代码自动符合eslint:规则
Commitizen：git commit -m "描述信息" ，描述信息的约定式提交规范
husky：是git hooks工具
commitlint: 用来检查提交信息
使用 husky + commitlint 检查提交描述是否符合规范要求
pre-commit 检测提交时代码规范
ESLint 与 Prettier只解决了本地代码格式化的问题，但是这些需要配置啥的，如果未配置直接提交了，此时的解决办法是husky 配合 eslint
lint-staged 自动修复格式错误,只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送

4工具配置

4.1 eslint

项目中包含一个 .eslintrc.js 文件，这个文件就是 eslint 的配置文件。

// 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"
  }
};  

4.2 prettier

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

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

{
  // 不尾随分号
  "semi": false,
  // 使用单引号
  "singleQuote": true,
  // 多行逗号分割的语法中，最后一行不加逗号
  "trailingComma": "none",
  // 方法名后面增加空格
  'space-before-function-paren': 'off'
}

3.在设置中，搜索 save ，勾选 Format On Save至此，你即可在 VSCode 保存时，自动格式化代码！
4.VSCode 而言，默认一个 tab 等于 4 个空格，而 ESLint 希望一个 tab 为两个空格,设置中的 Tab Size改为2
5.ESLint 和 prettier 之间的冲突问题--方法名和后面的小括号之间，应该有一个空格！

//.eslintrc.js的rules 规则下，新增一条规则
'space-before-function-paren': 'off'

4.3 Commitizen

commitizen 仓库名为 cz-cli ，它提供了一个 git cz 的指令用于代替 git commit，简单一句话介绍它：
当你使用 commitizen 进行代码提交（git commit）时，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 Hooks，即希望git commit命令不变来看到提示内容）

4.4 husky

git hooks常用
简单来说这两个钩子：

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

2.pre-commit：会在提交前被调用，并且可以按需指定是否要拒绝本次提交

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

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

配置
1.安装依赖

npm set-script prepare "husky install"

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

npx husky install

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

npm set-script prepare "husky install"

4.执行 prepare 指令

npm run prepare

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

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

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

4.5通过 pre-commit 检测提交时代码规范（husky（pre-commit 是钩子之一）配合 eslint）

1.执行 npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src" 添加 commit 时的 hook （npx eslint --ext .js,.vue src 会在执行到该 hook 时运行）
该操作会生成对应文件 pre-commit
2.关闭 VSCode 的自动保存操作
3.修改一处代码，使其不符合 ESLint 校验规则
4.执行 提交操作 会发现，抛出一系列的错误，代码无法提交
5.想要提交代码，必须处理完成所有的错误信息
那么到这里位置，我们已经通过 pre-commit 检测到了代码的提交规范问题。
！！到这之后需要引出lint-staged，来自动修复提交时的错误

4.6lint-staged 自动修复格式错误

pre-commit 处理了 检测代码的提交规范问题，当我们进行代码提交时，会检测所有的代码格式规范 。存在两个问题
1.我们只修改了个别的文件，没有必要检测所有的文件代码格式
2.它只能给我们提示出对应的错误，我们还需要手动的进行代码修改

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 的内容，被自动修复