格式相关--Eslint、vetur、prettier、hooks、huscky、commitlint、commitizen

Eslint

eslint不仅作代码规范，还有检查变量声明了是否调用，是否有console.log语句等，就是同时兼顾代码格式和代码质量。

eslint的安装看本文档的下面章节：eslint安装、eslintrc配置项

Eslint有npm包和vscode插件
如果只安装npm包，只能通过运行eslint index.js，看到控制台报错：

安装vscode插件之后，就能看到带波浪线的报错效果了，一边写代码的时候就能直接看到错误，然后就能直接随手改正错误：

为什么npm包和vscode插件最好要同时安装：
虽然vscode插件也可以单独配置格式，但是如果项目中有.eslintrc.js文件，那么eslint插件会优先执行.eslintrc.js文件的配置。
并且不是每个人都会装eslint的vscode插件。此时eslint的npm包就作为一个保障，并且里面的.eslintrc.js配置就作为标准配置。

vscode插件可以读取npm包的eslintrc的配置，然后波浪线报错：
例如配置完eslint-plugin-compat后，如下波浪线报错：
(eslint-plugin-compat的配置在后面章节)

原始的eslint只能校验js文件，但是配合eslint插件eslint-plugin-vue(配置方式在后面章节)，使eslint也可以校验.vue文件中html代码，js代码，css代码：

但是eslint并没有插件可以校验.html、.less、.css等类型文件的插件。
例如.less文件如下格式，eslint并不会波浪线报错：

eslint对html代码和css代码的校验能力很弱，html代码和css代码需要依靠prittier来格式化。

校验和格式化是两回事。校验是波浪线提示你哪里错了，格式化是一键帮你修复有问题的代码。

Prettier

可作用于js,vue,html,css,scss,json,reactjs等大部分场景，暂时还不能格式化vue模版文件中template部分

Prettier也有npm包和vscode插件。
安装npm包后，运行npx prettier --write index.js，可以立马让代码变得工工整整：

安装vscode插件的目的：
还是和eslint一样的老问题，我需要每次执行npx prettier --write .才会修改格式。我想要在我写代码的时候，一Ctrl+S保存就能自动格式化代码
安装完vscode插件后，右键可以看到如下：

即使prettier和vetur都不安装，vscode右键格式化，也有vscode自带的格式化功能，可以对html、js、css等格式化。

相关配置建议写在.prettierrc.js，不写在settings.json里，因为settings.json不方便跟随代码提交git，而且有些开发者可能不配置settings.json，没有约束性。

很多项目不使用prettier的原因是，即使配置了.prettierrc.js文件，并提交到了git，如果开发人员不手动执行格式化，不配置保存自动修复，也能成功提交到git，所以说没有约束力。而且也没有波浪线报错提示，也没有控制台报错提示。而eslint是有约束力也有报错提示的。

Vetur

• 语法高亮
• 格式化
• 调试，以及错误检查
• 全局组件的定义提示等等

安装vetur之前：

安装vetur之后，代码有了颜色：

安装vetur之后，右键格式化，能看到vetur选项：

可以看到.vue文件里有波浪线报错：

vetur可以在vscode的setting.json中配置一些它自己的规则，但是不建议这么做。建议只使用vetur的代码高亮功能。

Eslint、vetur、prettier三者之间的关系

eslint和prettier规则冲突的解决办法：
(冲突就是指规则相反，如它用单引号它却用双引号)

• 只使用eslint，不使用prettier
• 认真核对eslintrc和prettierrc文件，保证没有冲突的规则
• 让eslint按照prettier的规则来检测代码质量
• 只用Prettier插件来美化代码，用ESLint插件来检查代码质量

让eslint按照prettier的规则来检测代码质量
使用到两个插件eslint-config-prettier和eslint-plugin-prettier
eslint-config-prettier：
会调用prettier对你的代码风格进行检查，其原理是先使用prettier对你的代码进行格式化，然后与格式化之前的代码进行对比，如果过出现了不一致，这个地方就会被prettier进行标记。
接下来，我们需要在rules中添加，"prettier/prettier": "error"，表示被prettier标记的地方抛出错误信息。
使用方法：

//.eslintrc.js
{
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error"
  }
}

eslint-plugin-prettier：
能够关闭一些不必要的或者是与prettier冲突的rules选项
使用方法：

//.eslintrc.js
{
  extends: [
    'standard', //使用standard做代码规范
    "prettier",
  ],
}

同时使用上面两个插件，简化配置：

{
  extends: [
    "plugin:prettier/recommended"
  ],
  rules: { 
    "prettier/prettier": "error"
  }
}

如上配置后，eslint的vscode插件会按照.eslintrc.js文件的配置，也就是100%按照prettier规则来进行波浪线提示，同时运行npm run dev，控制台也会按照prettier规则来报错；即使双方某个规则冲突，也是按照prettier的来。
如果想按照自己的想法修改规则，只有一种方法，就是.eslintrc.js文件里的rules的prettier/prettier里面改：

rules: { 
    'prettier/prettier': ['error', { singleQuote: true }]
}

直接在rules里改无效：

rules: { 
    'quotes': [1, 'single'] // 使用单引号
}

直接在rules里会导致，当修改为单引号时，prettier/prettier提示应该为双引号，当又修改为双引号时，rules里的quotes又提示应该为单引号，进入了死循环

直接在.prettierrc.js改也无效，因为eslint-config-prettier不会去
读取.prettierrc.js

只用Prettier插件来美化代码，用ESLint插件来检查代码质量

module.exports = {
    extends: ["eslint:recommended", "prettier"], 
    // 这里没有使用 eslint-plugin-perttier,只使用了eslint-config-prettier
};

只使用eslint-config-prettier的目的是，当右键使用prettier格式化代码后，运行npm run dev后eslint检测代码时，当eslint某个规则和prettier冲突时，将不对已经格式化后的代码报错。

prettier默认规则时(双引号)，eslint也默认规则时(单引号)，eslint-config-prettier可忽略掉冲突

prettier默认规则时(双引号)，eslint个性化配置(虽然说个性化设置，就在rules里显式的说明下使用当引号，其实默认就是单引号)，这种情况，eslint-config-prettier并不能忽略掉冲突

prettier个性化配置(设置为单引号)，eslint也个性化配置(设置为双引号)，这种情况，eslint-config-prettier也不能忽略掉冲突

prettier个性化配置(设置为双引号)，eslint默认规则时(单引号)，eslint-config-prettier可忽略掉冲突

总结来说，eslint-config-prettier可以忽略掉prettier和eslint的默认规则的冲突，如果因为手动修改eslintrc和prettierrc导致规则冲突，eslint-config-prettier并不能忽略掉冲突。

我目前参与的项目只使用了eslint，没有使用prettier

关于保存时自动修复格式

保存时自动修复eslint：

    //保存时自动修复eslint问题
     "editor.codeActionsOnSave": {
         "source.fixAll.eslint": true
     },
     // 让函数(名)和后面的括号之间加个空格
     "javascript.format.insertSpaceBeforeFunctionParenthesis": true,
     "vetur.format.defaultFormatter.js": "vscode-typescript"

当不使用eslint-config-prettier，也不使用eslint-plugin-prettier时，eslintrc文件里的rules也没有显式配置，即都是默认配置时，保存时是按照eslint默认配置修复。

当不使用eslint-config-prettier，也不使用eslint-plugin-prettier时，eslintrc文件里有配置自己的rules时，保存时按照rules的配置修复。

当只使用eslint-config-prettier时，并且eslint和prettier都是默认规则时，保存时，不会修复有冲突的规则。

当使用eslint-plugin-prettier和eslint-config-prettier时(具体用法看上面的章节)，并且配置'prettier/prettier': ['error', { singleQuote: true }]时，保存时能够按照prettier/prettier里的配置修复，即修复为单引号

当使用eslint-plugin-prettier和eslint-config-prettier时(具体用法看上面的章节)，并且配置"prettier/prettier": "error"时，保存时是按照prettier的规则修复，即使两者规则冲突，也是按照prettier修复。

可以总结说，保存时自动修复eslint这个配置，就是完全按照eslintrc文件来修复。

因为保存时自动修复eslint这个配置，是针对eslint的，所以那些eslint不能检测的文件类型，同样的也不能修复，目前只能修复.js .vue文件，.less .css文件不能修复。

下面这段是，保存时自动格式化，并且按照prettier格式化，即按照prettierrc文件格式化：

     "editor.formatOnSave": true, // 保存时自动格式化
     "[javascript]": {
         "editor.defaultFormatter": "esbenp.prettier-vscode", // 格式化时使用 prettier
     }

这个配置如何和前面的保存时自动修复eslint的配置一起使用的话，当遇到eslint和prettier规则冲突的时候，会出现诡异的事，vscode会先调用eslint修复变成单引号，再调用prettier格式化变成双引号，最后会因为不满足eslint的单引号配置而报错波浪线。

这个配置如何和前面的保存时自动修复eslint的配置一起使用，并且还同时使用了eslint-config-prettier和eslint-plugin-prettier，并且存在规则冲突：
.prettierrc:

{
    "singleQuote": true,
    "semi": true,
}

.eslintrc:

module.exports = {
    extends: ["eslint:recommended", "plugin:prettier/recommended"],
    ...其它配置
};

vscode会先调用eslint修复变成双引号(因为同时了eslint-config-prettier和eslint-plugin-prettier，所以eslintrc文件的最终效果是按照prettier的规则，及双引号)，再调用prettier格式化变成单引号，最后会因为不满足eslint的单引号配置而报错波浪线。

保存时自动格式化这个配置可以自动格式化的文件：.less .vue .js
不可以自动格式化的文件：.html .vue文件里的template部分

eslint安装

1.生成pachage.json文件：npm init -f

2.安装eslint：npm add eslint -d

3.初始化eslintrc文件：npx eslint --init

eslintrc配置项

env：

指定脚本的运行环境。每种环境都有一组特定的预定义全局变量。
env: { browser: true }
表示可以使用浏览器环境的变量，如：window、document、alert

parserOptions：指定你想要支持哪些JavaScript语法
和env配置的区别是：

parserOptions.ecmaVersion表示支持哪个es版本的语法，在eslintrc文件里可以不配置，因为extends.standard表示继承standard里的默认配置，在node_modules里的eslint-config-standard里：

parserOptions: {
    parser: 'babel-eslint'
}

这里设置的配置项将会传递到解析器中，被解析器获取到，进行一定的处理。具体被利用到，要看解析器的源码有没有对其进行利用。这里仅仅做了参数定义，做了规定，告诉解析器的开发者可能有这些参数
配置项目有：
"sourceType": "module",  // 指定JS代码来源的类型，script(script标签引入？) | module（es6的module模块），默认为script。为什么vue的会使用script呢？因为vue是通过babel-loader编译的，而babel编译后的代码就是script方式
"ecmaVersion": 6,     // 支持的ES语法版本，默认为5。注意只是语法，不包括ES的全局变量。全局变量需要在env选项中进行定义
"ecmaFeatures": {     // Features是特征的意思，这里用于指定要使用其他那些语言对象
"experimentalObjectRestSpread": true, //启用对对象的扩展
"jsx": true,              //启用jsx语法
"globalReturn":true,          //允许return在全局使用
"impliedStrict":true          //启用严格校验模式

settings:

  settings: {
    'import/resolver': {
      webpack: {
        config: 'build/webpack.base.config.js',
      },
    },
    "polyfills": [
      // Example of marking entire API and all methods and properties as polyfilled
      "Promise",
      "IntersectionObserver",
      // Example of marking specific method of an API as polyfilled
      "WebAssembly.compile",
      // Example of instance method, must add `.prototype.`
      "Array.prototype.push"
    ]
  }

规则共享参数
提供给具体规则项，每个参数值，每个规则项都会被注入该变量，但对应规则而言，有没有用，就看各个规则的设置了，就好比 parserOptions，解析器用不用它就不知道了。这里只是提供这个方法
如上面的

    'import/resolver': {
      webpack: {
        config: 'build/webpack.base.config.js',
      },
    },

globales:

extends:

extends: [
    'plugin:vue/essential',
    'standard',
    'plugin:compat/recommended',
]

 extends: [
    'plugin:vue/essential',
    '@vue/standard'
]
plugins: [
    "vue",
    "compat"
]

用户可以轻松使用vue/essential、standard样式指南中的编码约定，而无需从头开始编写设置

plugin:compat/recommended这种是合并后的写法，原写法是：

 extends: [
    "compat",
 ],
"plugins": ["compat"]

plugins:

plugins: [
    "vue",
    "compat"
]

ESLint提供的默认规则涵盖了基本规则，但JavaScript可以使用的范围非常广泛。因此，您可能希望规则不在默认规则中。在这种情况下，可以在ESLint中开发自己的独立规则。为了让第三方开发自己的规则，ESLint允许使用插件。如果你在npm中搜索eslint-plugin- *，你可以找到第三方提供的大量自定义插件。
如果ESLint的默认规则未提供您要使用的规则，则建议您查找插件。
与可共享配置类似，它很容易设置。例如，如果要对React代码执行静态分析，可以安装名为eslint-plugin-react的插件，并使用以下设置来执行React语法特有的静态分析。
插件的作用类似于解析器，用以扩展解析器的功能，用于检测非常规的js代码。也可能会新增一些特定的规则。
如 eslint-plugin-vue，是为了帮助我们检测.vue文件中 <template> 和 <script> 中的js代码

plugins要引入对应的插件模块，然后一般还需要在rules里配置相对应的规则，比如：

  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error"
  }

  "plugins": ["vue"],
  "rules": {
    'vue/require-prop-types': 2, // prop 必须有类型限制
    'vue/no-async-in-computed-properties': 2, // 计算属性禁止包含异步方法
  }

  "plugins": ["compat"],
  "rules": {
    'compat/compat': 2
  }

rules：

rules: {
    'compat/compat': 2, // 设置为错误
    // allow async-await
    'generator-star-spacing': 'off'
}

“off” 或 0 - 关闭规则
“warn” 或 1 - 开启规则，使用警告级别的错误：warn (不会导致程序退出)
“error” 或 2 - 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)

eslint-plugin-compat兼容性验证插件的使用

compat [kəmˈpæt] n.兼容性
eslint-plugin-compat 是 ESLint 的一个插件，由前 uber 工程师 Amila Welihinda 开发。它可以帮助发现代码中的不兼容 API 。

使用步骤：
第一步：安装eslint-plugin-compat：

第二步：新增.browserslistrc文件：

这里的填写格式是遵循 browserslist （https://github.com/browsersli... ）所定义的一套描述规范。browserslist 是一套描述产品目标运行环境的工具，它被广泛用在各种涉及浏览器/移动端的兼容性支持工具中，例如 eslint-plugin-compat 、babel、Autoprefixer 等

第三步：修改.eslintrc.js文件：

npx eslint --init命令中的选项

（1）How would you like to use ESLint?
To check syntax only // 只检查语法性错误
To check syntax and find problems // 检查语法错误并且发现问题代码
To check syntax, find problems, and enforce code style // 检查语法错误，发现问题代码，校验代码风格

选第三个，检查语法错误，发现问题代码，校验代码风格

（2）What type of modules dos your project use?

JavaScript modules (import/export) // ESM：允许使用import/export
CommonJS (require/exports) // CommonJS：允许使用require/exports
None of these // 没有用到任何模块化

选第一个，import/export

（3）Which framework does you project use?

React

Vue.js

None of these

选vue

（4）Does your project use TypeScript? No / Yes

输入yes

（5）Where does you code run? // 多选

(*) Browser // 浏览器环境

(*) Node // node环境

选浏览器

（6）How would you like to define a style for your project?

Use a popular style guide // 使用一个市面上的主流风格
Answer questions about your style // 通过回答问题，形成一个风格
Inspect your JavaScript file(s) // 根据JS代码文件，推断代码风格

选第一个，市面主流风格

（7）Which style guide do you want to follow?

Airbnb: https://github.com/airbnb/jav...
Standard: https://github.com/standard/s...
Google: https://github.com/google/esl...

选第二个，开源

Vue脚手架初始化命令中的eslint选项

Vue2脚手架：

Vue3脚手架：

webpack中关于eslint的配置

1. overlay默认都为false，errors表示错误，warnings表示警告
   

设置为true后，浏览器会全屏显示错误，如下：

2.module.rules里的eslint-loader配置：

3. packge.json里script.lint配置

    "scripts": {
       "lint:eslint": "eslint --ext .js,.vue ./src"
     }

   本来只需要eslint ./src就行，因为是vue项目，需要识别.vue文件，
   所以使用eslint --ext .js,.vue ./src

4. 在运行npm run dev 时，webpack配置文件中很多插件，都能提示eslint错误，如下：
   

而且能够给各种类型的文件报错，.less文件，.vue文件，因为webpack配置文件里对这些类型的文件，都配置了loader或者plugin：

特别是webpack配置文件中的eslint-loader能够读取到eslintrc的配置内容，如下，compat是在eslintrc配置的：

禁用eslint规则的方式

某一行代码

也可以禁用一块代码或者整个文件：

可以指定禁用某个指定规则：

再配合vscode的eslint插件，来提示错误，这样就不需要每次手动去检查是否有错误。
建议项目组成员禁止使用vscode的保存时自动修复的功能，不能偷懒，一段时间后，大家都能形成很好的代码习惯。

vscode默认带有波浪线报错

错误写了中文分号，红色波浪线有如上提示，解决方法是：
第一步：
在设置中搜validate->往下滑找到Tyscript>Validate：Enable选项、Javascript>Validate：Enable选项，取消勾选

重启一下vscode就可以啦

.less文件有如下提示:

去掉这个提示的方法，不勾选如下选项：

hooks、huscky、commitlint

hooks

类似于前端框架中的生命周期钩子，git在某些特定事件发生前或后也会有某些执行特定功能的钩子，githooks就是在git执行特定事件（如commit、push、receive等）时触发运行的脚本。
githooks 保存在 .git 文件夹中。
用的多的钩子有：

pre-commit git commit 执行前

commit-msg git commit 执行前

husky

husky 是一个让配置 git 钩子变得更简单的工具。支持所有的git钩子。
安装：npm install husky --save-dev
安装完之后创建配置文件.huskyrc，文件里的内容：

{
  "hooks": {
   "pre-commit": "npm run lint:eslint"
  }
}

lint:eslint是在package.json中配置的：

"scripts": {
    "lint:eslint": "eslint --ext .js,.vue ./src"
}

--ext用来指定检测的文件格式，src是检测的目录。
eslint后面接--，都是eslint的自带命令，npx eslint --help可以查看所有命令

只使用husky，可以阻止提交不符合eslint规范的代码，但是无法限制提交描述文本，需要看下面的配置。

commitlint

检测git commit 提交说明是否符合规范。
需要安装两个相关的包：@commitlint/cli和@commitlint/config-conventional

commitlint需要配置一份校验规则，@commitlint/config-conventional就是符合Angular规范的一份校验规则。校验是指写好提交说明后，最后一步的校验，不关注过程是什么样的。
需要创建配置文件.commitlintrc.js，也可以命名为commitlint.config.js
在里面定义规范：(跟eslintrc文件的配置有一点相似)

module.exports = {
    extends:['@commitlint/config-conventional'],
    rules: {},
}

commitlint的执行需要配合husky，.huskyrc文件里配置如下：

{
  "hooks": {
    "commit-msg": "commitlint -e $GIT_PARAMS"
  }
}

这个$GIT_PARAMS，跟husky版本有关，高版本的写成$HUSKY_GIT_PARAMS

commitizen

上面的commitlint是检测提交信息是否合规，但是不能辅助生成标准化的提交信息，辅助的意思是，命令行输入git commit之后，有自动提示，是交互型命令行工具。
Commitizen是撰写合格 Commit message 的工具，用于代替git commit 指令。
Commitizen是一款提升GIT提交过程效率的小工具。它会提示你提供任何必要字段，还会恰当地格式化提交信息。
Commitizen内置了对多种提交规范的支持，同时还允许你定制自己的提交规则。这个简单的工具能够节约时间，而不必等待提交钩子运行检查再驳回提交。
凡是用到git commit命令，一律改为使用git cz。这时，就会出现选项，用来生成符合格式的 Commit message：

Commitizen下载后默认的适配器是 cz-conventional-changelog，适配器是规定命令行工具的交互方式的相关数据，即命令行每输入一个命令，会提示什么，提示选择之后，又是什么交互等等。

全局安装 commitizen 情况下可使用 git cz，未全局安装 commitizen 情况下可使用 npm run commit 来提交代码。
在package.json中配置命令：

"scripts": {
    "commit": "git-cz"
}

或者：

"scripts": {  
    "commit": "./node_modules/.bin/git-cz"
}

运行npm run commit之后

.czrc配置文件，是由commitizen读取的，可以在里面设置适配器，看后面章节的cz-conventional-changelog适配器和cz-customizable适配器。

后面插件名称中带有cz两个字符的都是跟commitizen有联系的插件。

cz-conventional-changelog

是commitizen的适配器，即更换 commitizen 命令行工具的交互方式的插件，是友好交互型命令行工具，使commitizen支持 Angular 的 Commit message 格式。
为commitizen指定适配器的方法：
 方法一：package.json中增加配置：

"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  }
}

方法二：更推荐创建.czrc配置文件(跟.eslintrc/.commitlintrc类似，带有rc两个字母)，在文件中设置：

{
  "path": "node_modules/cz-conventional-changelog"
}

cz-conventional-changelog的安装方式：
cz-conventional-changelog属于Commitizen的子依赖，所以package.json的devDependencies没有必要写cz-conventional-changelog。

cz-conventional-changelog默认规则是这样的：

cz-conventional-changelog无法自定义规则。如果开发者需要自定规则，得学习使用 inquirer 从头创造一个新的适配器，这实在是不太易用。如果需要自定义规则，请使用cz-customizable代替cz-conventional-changelog，cz-customizable 对外设定了一份配置文件 .cz-config.js，设计了一些可配置字段，cz-customizable 读入配置并将其转换为基于 inquirer 的命令行交互流程。

commitlint-config-cz和@commitlint/cz-commitlint

这个插件的命名规则很像eslint-config-prettier。
了解 commitlint 和 commitizen 的机制之后，我们来考虑核心问题：怎么使两者共用同一份规则配置。
有两种思路：
1.从 commitlint 配置出发，读取 commitlint 配置并生成对应的命令行提交流程，即创造一个 commitizen 适配器，@commitlint/cz-commitlint 已实现
2.从 cz-customizable 和cz-conventional-changelog的规则出发，将 cz-customizable 和cz-conventional-changelog规则翻译为 commitlint 规则，即创造一个 commitlint 配置，commitlint-config-cz 已实现。

commitlint-config-cz的使用：
commitizen 和 commitlint相关包安装和配置(看本文档的前面章节)成功之后。
安装commitlint-config-cz：npm install --save-dev commitlint-config-cz

需要在.commitlintrc.js或者commitlint.config.js文件里新增加cz这条配置：

module.exports = {
    extends: ['cz', '@commitlint/config-conventional'],
    rules: {},
};

@commitlint/cz-commitlint的使用：
commitizen 和 commitlint相关包安装和配置(看本文档的前面章节)成功之后。
在 package.json 中配置 commitizen 适配器

  "config": {
    "commitizen": {
      "path": "@commitlint/cz-commitlint"
    }
  }

参考文档：https://www.proyy.com/6975836...

我当前项目中的相关配置

@commitlint/cli：校验提交说明是否符合规范
@commitlint/config-conventional：符合Angular风格的校验规则
commitizen：撰写合格 Commit message 的工具，用于代替git commit 指令
commitlint-config-cz：使提交时的交互和校验同一套规则，用commitlint这边的规则
husky：让配置 git 钩子变得更简单的工具

git-cz是commitizen插件的命令。
commitizen是一个撰写合格 Commit message 的工具。
git-cz命令后会出现如下交互功能：

.commitlintrc.js也可以命名为commitlint.config.js
在里面定义规范。
这个配置文件是@commitlint/cli和@commitlint/config-conventional插件的。

该步骤的作用是为commitizen指定适配器，是commitizen的适配器，使commitizen支持 Angular 的 Commit message 格式

这个项目只配置了commit-msg钩子，所以只会校验提交信息。
需要校验代码格式，需要再配置pre-commit钩子来调用eslint。

其他一些插件

conventional-changelog：

可以快速生成开发日志

validate-commit-msg：

在package.json文件中增加下面这个，运行npm run changelog可以生成
日志

{
  "scripts": {
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"
  }

生成如下这种日志：

cz-customizable：

安装：npm install cz-customizable --save-dev

定制提交格式规则的插件。
也是commitizen的适配器，即更换 commitizen 命令行工具的交互方式的插件，是友好交互型命令行工具

package.json中增加配置：

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

可以在项目根目录创建cz-config.js配置文件，在里面自定义规则：

'use strict';

module.exports = {

  types: [
    {value: '特性',     name: '特性:    一个新的特性'},
    {value: '修复',      name: '修复:    修复一个Bug'},
    {value: '文档',     name: '文档:    变更的只有文档'},
    {value: '格式',    name: '格式:    空格, 分号等格式修复'},
    {value: '重构', name: '重构:    代码重构，注意和特性、修复区分开'},
    {value: '性能',     name: '性能:    提升性能'},
    {value: '测试',     name: '测试:    添加一个测试'},
    {value: '工具',    name: '工具:    开发工具变动(构建、脚手架工具等)'},
    {value: '回滚',   name: '回滚:    代码回退'}
  ],

  scopes: [
    {name: '模块1'},
    {name: '模块2'},
    {name: '模块3'},
    {name: '模块4'}
  ],

  // it needs to match the value for field type. Eg.: 'fix'
  /*
  scopeOverrides: {
    fix: [
      {name: 'merge'},
      {name: 'style'},
      {name: 'e2eTest'},
      {name: 'unitTest'}
    ]
  },
  */
  // override the messages, defaults are as follows
  messages: {
    type: '选择一种你的提交类型:',
    scope: '选择一个scope (可选):',
    // used if allowCustomScopes is true
    customScope: 'Denote the SCOPE of this change:',
    subject: '短说明:\n',
    body: '长说明，使用"|"换行(可选)：\n',
    breaking: '非兼容性说明 (可选):\n',
    footer: '关联关闭的issue，例如：#31, #34(可选):\n',
    confirmCommit: '确定提交说明?'
  },

  allowCustomScopes: true,
  allowBreakingChanges: ['特性', '修复'],

  // limit subject length
  subjectLimit: 100

};

lint-staged

只检测git add . 中暂存区的文件，对过滤出的文件执行脚本
安装：npm install lint-staged --save-dev

 "husky": {
    "hooks": {
      "pre-commit": "lint-staged" // pre-commit，提交前的钩子
    }
  },

  "lint-staged": {
    // 此处可以配置文件夹和文件类型的范围
    "src/**/*.{jsx,txs,ts,js,json,css,md}": [
      "prettier --write", // 先使用prettier进行格式化
      "eslint --fix", // 再使用eslint进行自动修复
      "git add" // 所有通过的话执行git
    ]
  }

当不使用prettier格式化和eslint自动修复时，配置如下：

"lint-staged": {
  "**/*.js": "eslint"
},

vscode辅助填写提交内容的插件

当配置husky的commit-msg钩子后，在vscode点击暂存，随便写点提交内容，再点击commit之后：

vscode会报如下错误：

这个弹框是因为commitlint校验不通过。

手动填写提交信息很难达到校验标准，这个时候应该使用命令行运行 npm run commit。
点击暂存之后，控制台运行 npm run commit：

以上命令行交互是Commitizen实现的。

因为vscode提交已经习惯了用按钮去提交，之后提交需要用npm run commit替代git commit指令进行提交。会改变整个操作流程，在团队里推广不了。

可以使用vscode中的git-commit-plugin插件：

使用步骤：

安装提示一步一步往下填写信息，写完scope,subject body footer，然后点击complete完成编写。