关于前端:格式相关Eslintveturprettierhookshusckycommitlintcommitizen

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, // 保留时主动格式化
     "": {"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 实现编写。