前端自动化--git篇

git作为代码版本控制工具，已经深入到前端各个工程项目中，但在实际工作中，我们希望在提交代码时，验证一些代码规范和git commit时一些规范信息功能。

代码风格和性格一样，每个程序员都有自己的特点，但对于大家协同开发的项目，还是需要力求代码风格的一致性，以减少Bug，方便互相修改，短时间内能上手，在这条路上诞生了许许多多的工具。

初始化项目

//创建 git-test目录
mkidr git-test
//初始化项目目录
npm init -y 
或者
yarn init -y
//初始化git 
git init

Husky

Husky就是，在代码被提交到Git仓库之前，我们可以在这里做一些预检查或者格式化，需要做这些操作，我们需要一个Git的提交钩子，简单说就是使用Git命令会触发的函数。

安装

npm install husky --save-dev
或者
yarn add husky --dev

配置

//package.json
{
  "name": "git-test",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "husky": {
    "hooks": {
      "pre-commit": "yarn run test"
    }
  },
  "devDependencies": {
    "husky": "^3.1.0"
  }
}

在1.0.0之后的版本支持了使用.huskyrc，.huskyrc.json，.huskyrc.js配置文件，可以不放在package.json中。

//.huskyrc.js
module.exports = {
    "hooks": {
      "pre-commit": "yarn run test"
    }
}

Husky支持的Git Hooks还是很全面的，下面介绍几个常用的：

pre-commit 这个钩子被 git commit 命令调用

commit-msg 存有当前提交信息的临时文件的路

实例

git add
git commit -m 'a'
//系统提示
husky > pre-commit (node v12.13.1)
yarn run v1.19.1
$ echo "Error: no test specified" && exit 1
Error: no test specified
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
husky > pre-commit hook failed (add --no-verify to bypass)

Commitlint

Commitlint是代码的提交规范和规范的校验，优雅的提交，方便团队协作和快速定位问题

安装

npm install @commitlint/config-conventional @commitlint/cli --save-dev
或者
yarn add @commitlint/config-conventional @commitlint/cli --dev

配置

Commitlint的配置文件可以是commitlint.comfig.js或者.commitlintrc.js

//生成配置文件
echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js

//package.json
{
  "name": "git-test",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "test": "echo \"Error: no test specified\""
  },
  "husky": {
    "hooks": {
      "pre-commit": "yarn run test",
      //新增加
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
  "devDependencies": {
    "@commitlint/cli": "^8.2.0",
    "@commitlint/config-conventional": "^8.2.0",
    "husky": "^3.1.0"
  }
}

定制提交规范

提交格式(注意冒号后面客格)

<type>: <subject>

常用的type类别

需要根commitlint配置文件里设置的一样，这个配置文件将在后面介绍，这里假设设置了这些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 功能'

subject

subject是 commit 目的的简短描述，可以做一些配置，如最大长度限制。

commitlint.config.js文件配置

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    // Header
    'header-max-length': [2, 'always', 200],
    // <type> 不能为空
    'type-empty': [2, 'never'],
    // <type> 格式 小写
    'type-case': [2, 'always', 'lower-case'],
    // <scope> 格式 小写
    'scope-case': [2, 'always', 'lower-case'],
    // <subject> 不能为空
    'subject-empty': [2, 'never'],
    // <subject> 以.为结束标志
    'subject-full-stop': [2, 'never', '.'],
    // <subject> 格式
    // 可选值
    // 'lower-case' 小写 lowercase
    // 'upper-case' 大写 UPPERCASE
    // 'camel-case' 小驼峰 camelCase
    // 'kebab-case' 短横线 kebab-case
    // 'pascal-case' 大驼峰 PascalCase
    // 'sentence-case' 首字母大写 Sentence case
    // 'snake-case' 下划线 snake_case
    // 'start-case' 所有首字母大写 start-case
    'subject-case': [2, 'never', []],
    // <body> 以空行开头
    'body-leading-blank': [1, 'always'],
    // <footer> 以空行开头
    'footer-leading-blank': [1, 'always'],
    //rule由name和配置数组组成，如：'name:[0, 'always', 72]'，
    //数组中第一位为level，可选0,1,2，0为disable，1为warning，2为error，
    //第二位为应用与否，可选always|never，
    //第三位该rule的值
    'type-enum': [
      2,
      'always',
      [
        'build', // 构建
        'ci', // ci
        'chore', // Other changes that don't modify src or test files. 改变构建流程、或者增加依赖库、工具等
        'docs', // Adds or alters documentation. 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
        'feat', // Adds a new feature. 新增feature
        'fix', // Solves a bug. 修复bug
        'perf', // Improves performance. 优化相关，比如提升性能、体验
        'refactor', // Rewrites code without feature, performance or bug changes. 代码重构，没有加新功能或者修复bug
        'revert', // Reverts a previous commit. 回滚到上一个版本
        'style', // Improves formatting, white-space. 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
        'test' // Adds or modifies tests. 测试用例，包括单元测试、集成测试等
      ]
    ]
  }
 }

Lint-staged

Lint-staged代码的格式化肯定会涉及到文件系统，一般工具会首先读取文件，格式化操作之后，重新写入。对于较大型的项目，文件众多，首先遇到的就是性能问题，虽然如Eslint之类的也有文件过滤配置，但毕竟还是对于匹配文件的全量遍历，如全量的.js文件，基本达不到性能要求，有时还会误格式化其他同学的代码，因此我们引入Lint-staged，一个仅仅过滤出Git代码暂存区文件(被committed的文件)的工具。

安装

npm install --save-dev lint-staged
或者
yarn add lint-staged --dev

配置

Lint-staged仅仅是文件过滤器，不会帮你格式化任何东西，所以没有代码规则配置文件，需要自己配置一下，如：.eslintrc、.stylelintrc等，然后在package.json中引入

当文件变化，我们git commit它们，pre-commit钩子会启动，执行lint-staged命令，我们对于lint-staged如上文配置，对本次被commited中的所有.js文件，执行eslint --fix命令和git add,命令，前者的的目的是格式化，后者是对格式化之后的代码重新提交。

除了在package.json中配置，也可以在.lintstagedrc、lint-staged.config.js文件中，lint-staged的常用选项除了liners之外，还有ignore、concurrent等，具体参考文档：

"lint-staged":{
  "linters":{
    "*.{js}":["some command","git add"]
  },
  "ignore":["**/dist/*.min.js"]
}

常用的文件过滤，lint-staged 的格式如下

"lint-staged": {
  "src/**/*.{js,vue,ts}": [
    "eslint --fix",
    "git add"
  ],
  "src/**/*.{vue,css}": [
    "stylelint",
    "git add ."
  ],
  "src/**/*.{vue,scss}":[
     "stylelint --syntax=scss",
    "git add ."
  ],
  "src/**/*.{vue,less}":[
     "stylelint --syntax=less",
    "git add ."
  ]
}

prettier

Prettier](prettier.io/)是一个支持多语言的代码格式工具，如常用的：js、jsx、Vue、Flow、Ts、HTML、CSS等，非常全面，将代码解析为AST，然后重新组装，目的是最终输出风格统一的代码，对比eslint对error的fix要强一些，如最大长度的改动，eslint只是对有问题的地方进行格式化修改，不改动源代码风格，而prettier是对全量的代码进行格式化。

安装

npm install --save-dev prettier pretty-quick
或者
yarn add prettier pretty-quick --dev

配置

一共有三种方式支持对Prettier进行配置：

根目录创建.prettierrc文件，能够写入YML、JSON的配置格式，并且支持.yaml/.yml/.json/.js后缀；
根目录创建.prettier.config.js文件，并对外export一个对象；
在package.json中新建prettier属性。

下面我们使用prettierrc.js的方式对prettier进行配置，

module.exports = {
  "printWidth": 80, //一行的字符数，如果超过会进行换行，默认为80
  "tabWidth": 2, //一个tab代表几个空格数，默认为80
  "useTabs": false, //是否使用tab进行缩进，默认为false，表示用空格进行缩减
  "singleQuote": false, //字符串是否使用单引号，默认为false，使用双引号
  "semi": true, //行位是否使用分号，默认为true
  "trailingComma": "none", //是否使用尾逗号，有三个可选值"<none|es5|all>"
  "bracketSpacing": true, //对象大括号直接是否有空格，默认为true，效果：{ foo: bar }
  "parser": "babylon" //代码的解析引擎，默认为babylon，与babel相同。
}

辅助工具(看你的心情需要不需要安装了)

gitmoji:在提交时,使用符gitmoji交互式

安装

npm i -g gitmoji-cli
或者
yarn add -g gitmoji-cli

命令

Usage
    $ gitmoji
  Options
    --init, -i      Initialize gitmoji as a commit hook
    --remove, -r    Remove a previously initialized commit hook
    --config, -g    Setup gitmoji-cli preferences.
    --commit, -c    Interactively commit using the prompts
    --list, -l      List all the available gitmojis
    --search, -s    Search gitmojis
    --version, -v   Print gitmoji-cli installed version
    --update, -u    Sync emoji list with the repo

参考文章：

前端代码风格自动化系列（二）之Commitlint

使用ESLint+Prettier来统一前端代码风格

github.com/jiumao-org/…