关于前端:编码规范代码提交规范全家桶之huskylintstagedcommitlint

背书简介

husky，是一个为 git 客户端减少 hook 的工具。装置后，它会主动在仓库中的 .git/ 目录下减少相应的钩子；比方 pre-commit 钩子就会在你执行 git commit 的触发。咱们能够在 pre-commit 中实现一些比方 lint 查看、单元测试、代码丑化等操作。当然，pre-commit 阶段执行的命令当然要保障其速度不要太慢，每次 commit 等很久体验不好。

lint-staged，一个仅仅过滤出 Git 代码暂存区文件 (被 git add 的文件) 的工具；这个很实用，因为咱们如果对整个我的项目的代码做一个查看，可能耗时很长，如果是老我的项目，要对之前的代码做一个代码标准查看并批改的话，这可能就麻烦了，可能导致我的项目改变很大。所以这个 lint-staged，对团队我的项目和开源我的项目来说，是一个很好的工具，它是对集体要提交的代码的一个标准和束缚。

新版 husky 的工作原理

新版的 husky 从 git 2.9 开始引入一个新性能 core.hooksPath，core.hooksPath 能够让你指定 git hooks 所在的目录而不是应用默认的.git/hooks/，这样 husky 能够应用 husky install 将 git hooks 的目录指定为.husky/，而后应用 husky add 命令向.husky/ 中增加 hook。通过这种形式咱们就能够只增加咱们须要的 git hook，而且所有的脚本都保留在了一个中央（.husky/ 目录下）因而也就不存在同步文件的问题了。

新版 husky + lint-staged 实际

1. 装置 husky

npm i husky --save-dev

2. 在package.json 中增加 prepare 脚本

{
  "scripts": {"prepare": "husky install"}
}

3. 执行 prepare 脚本

npm run prepare

• 执行 husky install命令，该命令会创立.husky/ 目录并指定该目录为 git hooks 所在的目录。

4. 增加 git hooks，运行一下命令创立 git hooks

npx husky add .husky/pre-commit "npm run lint"

• 运行完该命令后咱们会看到.husky/ 目录下新增了一个名为 pre-commit 的 shell 脚本。也就是说在在执行 git commit 命令时会先执行 pre-commit 这个脚本。pre-commit 脚本内容如下：

  #!/bin/sh
  . "$(dirname"$0")/_/husky.sh"
   
  npm run lint

• 该脚本的性能就是执行 npm run lint 这个命令

  5. 增加 commit-msg 脚本

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

• commit-msg 脚本内容如下：

  #!/bin/sh
  
  "$(dirname"$0")/_/husky.sh"
  
  npx --no-install commitlint --edit "$1"

  6. 装置lint-staged

npm i lint-staged --save-dev

7. 在 package.json 文件中配置 lint  的命令

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

8. 在 package.json 或者在根目录中创立 .lintstagedrc 或者 lint-staged.config.js 或者 lint-staged.config.js文件中配置 lint  的命令

• 从 v3.1 开始，您当初能够应用不同的形式进行 lint-staged 配置：
• lint-staged 在你的对象 package.json
• .lintstagedrc JSON 或 YML 格局的文件
• lint-staged.config.js JS 格局的文件

• 应用 –config 或 -c 标记传递配置文件

  1. 例子：在 package.json 文件中配置

  "lint-staged": {"src/**/*.{js.vue}": ["prettier --write","esslint --cache --fix","git add"]
  }

  2. 例子：在 lint-staged.config.js 文件中配置

  "use strict";
  module.exports = {ignore: ["package-lock.json", "CHANGELOG.md"],
    linters: {"*.ts": ["prettier --write", "eslint --fix", "git add"],
        "*.js": ["prettier --write", "eslint --cache --fix", "git add"],
        "*.vue": ["prettier --write", "eslint --cache --fix", "git add"],
        "*.{json,md,yml,css}": ["prettier --write", "git add"]
  }

  在 commit 之前，将暂存区的内容做一次 代码查看 和 代码丑化，而后再增加到暂存区；而后再 commit

9. 定制提交标准

1. 装置

   npm install --save-dev @commitlint/config-conventional @commitlint/cli
   
   // 生成配置文件 commitlint.config.js，当然也能够是 .commitlintrc.js
   echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js

2. 定制提交格局

   <type>: <subject>

3. 罕用的 type 类别

• upd：更新某性能（不是 feat, 不是 fix）
• feat：新性能（feature）
• fix：修补 bug
• docs：文档（documentation）
• style：格局（不影响代码运行的变动）
• refactor：重构（即不是新增性能，也不是批改 bug 的代码变动）
• test：减少测试
• chore：构建过程或辅助工具的变动

例子：

git commit -m 'feat: 减少 xxx 性能'
git commit -m 'bug: 修复 xxx 性能'

4. commitlint.config.js 文件配置

rule 由 name 和配置数组组成，如：'name:[0,'always', 72]'，数组中第一位为 level，可选0,1,2，0 为 disable，1 为 warning，2 为 error，第二位为利用与否，可选always|never，第三位该 rule 的值。具体配置例子如下：

module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    'type-enum': [2, 'always', ['upd', 'feat', 'fix', 'refactor', 'docs', 'chore', 'style', 'revert']],
    'type-case': [0],
    'type-empty': [0],
    'scope-empty': [0],
    'scope-case': [0],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never'],
    'header-max-length': [0, 'always', 72]
  }
};

10. 装置 eslint 和 prettier 相干代码格式化和校验插件，我的项目根目录上面配置 eslint 和 prettier 规定，而后就能够在 git 提交代码的时候进行代码校验了。

• 例子：正确的提交

• 例子：谬误的提交