代码规范是软件开发领域经久不衰的话题，几乎所有工程师在开发过程中都会遇到或思考过这一问题。而随着前端应用的大型化和复杂化，越来越多的前端团队也开始重视代码规范。同样，前段时间，笔者所在的团队也开展了一波开源治理，而其中代码规范就占据了很重要的一项。接下来的几篇文章，将会对JS代码规范、CSS规范、Git提交规范以及Git工作流规范进行详细的介绍~
本文主要介绍了前端规范之JS代码规范（ESLint + Prettier），将会对ESLint和Prettier的使用进行介绍，欢迎大家交流讨论~

1. 统一代码风格的重要性

1.1 为什么要统一代码风格

团队千千万，团队中每个人的代码风格也是千千万。比如有的同学写代码就喜欢用双引号，缩进用两个字符，而其他同学却可能更喜欢用单引号，四个字符缩进。而团队中的人一多，一往代码仓库提交代码，难免会出现下面这些情况：

（1）如果没有统一代码风格，diff时可能会出现很多因为格式不同的问题，不便于我们查看提交代码所做的修改

如下图所示，提交的文件内容其实没有变化，只是代码风格变了（双引号变成了单引号，缩进从两个字符变成了四个字符），但是diff时大段代码会标红，不利于我们查看提交的修改。

（ 2）每个团队都有自己的标准，新人加入需要花较长时间才能熟悉团队所使用的代码风格，不利于效率的提

1.2 如何统一代码风格

为了统一代码风格，并且克服每个团队自己制定标准所带来的不足，一种简单方便的方法就是采用业界提供的标准和工具，也就是我们经常所说的Lint检查工具。前端中常用的Lint检查工具包括了JSLint、ESLint和Stylelint等，这些工具能够提供代码质量和代码风格检查的功能，并且可以根据个人/团队的代码风格进行对配置文件进行配置，有效的提高了我们代码开发的效率和质量。\

下面主要列举了我们团队现在主要采用的一些Lint检查工具，以及相关的VSCode辅助插件，帮助我们完成JS代码规范、CSS代码规范和Git工作流规范的检查。

2. ESLint

2.1 什么是ESLint

ESLint 是一款插件化的JavaScript代码静态检查工具，其核心是通过对代码解析得到的 AST（Abstract Syntax Tree，抽象语法树）进行模式匹配，来分析代码达到检查代码质量和风格问题的能力。

ESLint 的使用其实并不复杂。安装相关依赖之后，可以直接使用开源的配置方案，例如eslint-config-airbnb或eslint-config-standard，当然，你也可以根据个人或团队的代码风格进行配置。配置完成之后，就可以通过命令行工具或借助编辑器集成的 ESLint 功能对工程代码进行静态检查，发现和修复不符合规范的代码，ESLint提供的auto-fix能力也能够帮助我们自动修复一些代码格式问题。

2.2 安装ESLint

（1）脚手架自动安装

如果是采用脚手架如Vue-Cli创建项目，在创建项目时就可以选择安装ESLint，安装完成后，会自动在项目根目录生成一个.eslintrc.js文件，里面已经生成了ESLint的初始化默认配置。

****（2）手动安装

如果是已经存在一个项目，并且想要安装ESLint，可以通过npm的方式进行安装。

npm install eslint --save-dev
yarn add eslint --save-dev

安装完成后，可以执行下面命令进行ESLint的初始化配置。

npx eslint --init

经过一系列一问一答的环节后，你会发现在你项目根目录已经生成了一个 .eslintrc.js文件，该文件主要用来进行ESLint的配置。

2.3 ESLint配置方式

ESlint 被设计为完全可配置的，我们可以混合和匹配 ESLint 默认绑定的规则和自己定义的规则，根据实际需求对每一个规则进行开启或关闭，以让 ESLint 更适合我们的项目。一般有两种主要的方式来配置 ESLint：

（1）Configuration Comments - 使用注释把lint规则嵌入到源码中

****这种配置方式允许我们使用JavaScript注释把配置信息直接嵌入到一个代码源文件中，如下面的代码所示，可以直接在代码中使用ESLint能够识别的注释方式，进行Lint规则的定义，下面的规则表示如果使用console语法便会报错。

/* eslint no-console: "error" */
console.log('this is an eslint rule check!');

当我们用命令行执行eslint xxx.js检查上述文件时，就会发现eslint给出报错信息。

（2）Configuration Files - 使用配置文件进行lint规则配置

除了上面的配置方式，另外一个更好的方式就是在项目根目录创建配置文件进行ESLint的配置，目前配置文件主要支持以下三种文件类型：

JavaScript（eslintrc.js）
YAML（eslintrc.yaml）
JSON（eslintrc.json）

另外，我们也可以在package.json文件中添加 eslintConfig字段进行配置。

在我们团队平时的开发中，一般采用了在根目录创建.eslintrc.js的方式对eslint进行配置。如下图所示，给出了使用Vue-Cli创建项目后.eslintrc.js中的默认配置。

module.exports = {
  root: true,
  env: {
    node: true,
  },
  extends: ["plugin:vue/essential", "eslint:recommended", "@vue/prettier"],
  parserOptions: {
    parser: "babel-eslint",
  },
  rules: {
    "no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
    "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off",
  },
};

2.4 ESLint配置项解析

接下来主要对ESLint配置文件中的配置项进行介绍。

（1）parser解析器

ESLint 默认使用Espreer作为其解析器，但是该解析器仅支持最新的ECMPScript(es5)标准，对于实验性的语法和非标准（例如 Flow或TypeScript类型）语法是不支持的。因此，开源社区提供了以下两种解析器来丰富相关的功能：

babel-eslint：Babel一个工具链，主要用于将ECMAScript 2015+(es6+) 版本的代码转换为向后兼容的JavaScript语法，以便能够运行在当前和旧版本的浏览器或其他环境中。因此，如果在项目中使用es6，就需要将解析器改成babel-eslint。

@typescript-eslint/parser：该解析器将TypeScript转换成与estree兼容的形式，允许ESLint验证TypeScript源代码。

（2）parserOptions解析器选项

除了可以自定义解析器外，ESLint允许指定你想要支持的JavaScript语言选项。默认情况下，ESLint支持ECMPScript 5语法。你可以覆盖该设置，以启用对ECMPScript其它版本和JSX的支持。

（3）env和global - 环境和全局变量

ESLint 会检测未声明的变量，并发出警告，但是有些变量是我们引入的库声明的，这里就需要提前在配置中声明。每个变量有三个选项，writable，readonly和off，分别表示可重写，不可重写和禁用。

{
  "globals": {
    // 声明 jQuery 对象为全局变量
    "$": false, // true表示该变量为 writeable，而 false 表示 readonly
    "jQuery": false
  }
}

在globals中一个个的进行声明未免有点繁琐，这个时候就需要使用到env，这是对一个环境定义的一组全局变量的预设。当然，我们可以在golbals中使用字符串off禁用全局变量来覆盖env中的声明。

{
  "env": {
    "browser": true,
    "es2021": true,
    "jquery": true // 环境中开启jquery，表示声明了jquery相关的全局变量，无需在globals二次声明
  }
}

如果是微信小程序开发，env并没有定义微信小程序变量，需要在globals中手动声明全局变量，否则在文件中引入变量，会提示报错。声明如下所示：

{
  globals: {
    wx: true,
    App: true,
    Page: true,
    Component: true,
    getApp: true,
    getCurrentPages: true,
    Behavior: true,
    global: true,
    __wxConfig: true,
  },
}

4）rules规则

ESLint 附带有大量的规则，你可以在配置文件的rules属性中配置你想要的规则。要改变一个规则设置，你必须将规则 ID 设置为下列值之一：

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

如以下代码，在rules中设置关闭某些规则

rules: {'no-loop-func': 'off',
  'no-param-reassign': 'off',
  'no-nested-ternary': 'off',
   no-underscore-dangle': 'off',
},

（5）plugins插件

虽然官方提供了上百种的规则可供选择，但是这还不够，因为官方的规则只能检查标准的JavaScript语法，如果你写的是JSX或者TypeScript，ESLint 的规则就开始束手无策了。

这个时候就需要安装 ESLint 的插件，来定制一些特定的规则进行检查。ESLint 的插件与扩展一样有固定的命名格式，以eslint-plugin-开头，使用的时候也可以省略这个头。

举个例子，我们要在项目中使用TypeScript，前面提到过，需要将解析器改为@typescript-eslint/parser，同时需要安装@typescript-eslint/eslint-plugin插件来拓展规则，添加的plugins中的规则默认是不开启的，我们需要在rules中选择我们要使用的规则。也就是说 plugins是要和rules结合使用的。如下所示：

// npm i --save-dev @typescript-eslint/eslint-plugin    // 注册插件
{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],   // 引入插件
  "rules": {
    "@typescript-eslint/rule-name": "error"    // 使用插件规则
    '@typescript-eslint/adjacent-overload-signatures': 'error',
    '@typescript-eslint/ban-ts-comment': 'error',
    '@typescript-eslint/ban-types': 'error',
    '@typescript-eslint/explicit-module-boundary-types': 'warn',
    '@typescript-eslint/no-array-constructor': 'error',
    'no-empty-function': 'off',
    '@typescript-eslint/no-empty-function': 'error',
    '@typescript-eslint/no-empty-interface': 'error',
    '@typescript-eslint/no-explicit-any': 'warn',
    '@typescript-eslint/no-extra-non-null-assertion': 'error',
    ...
  }
}

（6）extends扩展

extends可以理解为一份配置好的plugin和rules，extends属性值一般包括以下两种：\

指定配置的字符串: 比如官方提供的两个拓展eslint:recommended或eslint:all，可以启用当前安装的 ESLint 中所有的核心规则，省得我们在rules中一一配置。
字符串数组：每个配置继承它前面的配置。如下所示，拓展是一个数组，ESLint 递归地扩展配置, 然后使用rules属性来拓展或者覆盖extends配置规则。

{
    "extends": [
        "eslint:recommended", // 官方拓展
        "plugin:@typescript-eslint/recommended", // 插件拓展
        "standard", // npm包，开源社区流行的配置方案，比如：eslint-config-airbnb、eslint-config-standard
    ],
    "rules": {
     "indent": ["error", 4], // 拓展或覆盖extends配置的规则
        "no-console": "off",
    }
};

2.5 运行ESLint检查文件

当我们配置好.eslintrc.js文件后，我们就可以通过运行ESLint相关命令，对指定文件进行检查，假设当前的项目目录如下所示：

其中，.eslintrc.js文件的配置如下，这里采用了Vue-Cli创建项目后给出的默认配置。

module.exports = {
  root: true,
  env: {
    node: true,
  },
  extends: ["plugin:vue/essential", "eslint:recommended", "@vue/prettier"],
  parserOptions: {
    parser: "babel-eslint",
  },
  rules: {
    "no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
    "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off",
  },
};

当我们想对某个文件进行检查时，只需要在当前目录打开命令行窗口，输入以下命令，就可以对某个文件或某个目录下的所有文件进行检查。如果执行完命令后什么也没有输出，就说明我们的代码已经通过ESLint检查，可以放心提交代码。

eslint src/APP.vue　　// 检查指定的文件
eslint src/*.vue　　  // 检查src目录下的所有文件

但是如果出现以下提示或报错，就说明我们的代码没有通过ESLint的检查，需要按照提示进行修改。

有些同学一执行完上述命令，可能会吓了一跳，怎么报了这么多错误？不急，我们可以执行以下的ESLint自动修复命令，对一些错误进行自动修复。不过，这个命令只能自动修复一些代码格式上的错误（比如ESLint的配置要求需要使用双引号，但是写代码时采用了单引号而报错），对于一些语法错误，就需要我们手动去修复。

eslint src/APP.vue --fix   // 检查指定的文件，并且自动修复错误    
eslint src/*.vue --fix     // 检查src目录下的所有文件，并且自动修复错误

2.6 跳过ESLint的检查

在实际的使用场景中，我们可能存在某些文件或某行代码，希望能够跳过ESLint的检查，下面主要介绍了几种跳过ESLint检查的方式：

（1）使用注释跳过ESLint的检查

块注释：使用如下方式，可以在整个文件或者代码块禁用所有规则或者禁用特定规则：

/* eslint-disable */
alert('该注释放在文件顶部，整个文件都不会出现 lint 警告');

/* eslint-disable */
alert('块注释 - 禁用所有规则');
/* eslint-enable */

/* eslint-disable no-console, no-alert */
alert('块注释 - 禁用 no-console, no-alert 特定规则');
/* eslint-enable no-console, no-alert */

行注释：使用如下方式可以在某一特定的行上禁用所有规则或者禁用特定规则：

alert('禁用该行所有规则'); // eslint-disable-line

// eslint-disable-next-line
alert('禁用该行所有规则');

/* eslint-disable-next-line no-alert */
alert('禁用该行 no-alert 特定规则');

alert(
 '禁用该行 no-alert, quotes, semi 特定规则'
); /* eslint-disable-line no-alert, quotes, semi*/

（2）创建.eslintignore文件忽略某些文件的检查

在项目根目录创建.eslintignore文件，在该文件中添加需要跳过检查的文件名称，ESLint将会跳过这些文件的检查。如下所示，ESLint将会跳过dist、node_modules和package.json文件的检查。

dist
node_modules
package.json

3. Prettier

3.1 什么是Prettier

Prettier是一个代码格式化工具，可以格式化代码，但不具备代码检查功能，它可以通过解析代码并使用自己的规则重新打印它，并考虑最大行长来强制一致的样式，并在必要时包装代码，如今，它已成为解决所有代码格式问题的优选方案，支持多种语言，可以将ESLint和Prettier结合使用，提高代码质量。

3.2 为什么要用Prettier

上面Prettier的定义一看，是不是觉得和ESLint差不了多少？那么，有了ESLint，为什么还要用Prettier呢？

其实呀，ESLint虽然是一个代码检测工具，可以检测代码质量问题并给出提示，但是提供的格式化功能有限，在代码风格上面做的不是很好，并且也只能格式化JS，不支持CSS,HTML等语言。而在代码风格上面，Prettier具有更加强大的功能，并且能够支持包括 JavaScript、TypeScript、各种 CSS、Vue 和 Markdown 等前端绝大部分的语言和文件格式。因此，我们一般会将ESLint和Prettier一起结合起来使用，用ESLint进行代码校验，用Prettier统一代码风格。

3.3 安装Prettier

（ 1）脚手架自动安装

如果是采用脚手架如Vue-Cli创建项目，在创建项目时就可以选择安装Prettier，安装完成后，会自动在项目根目录生成一个.eslintrc.js文件，里面的默认配置中已经包含了prettier的相关扩展。

****（2）手动安装

如果已经存在一个项目，并且想要安装Prettier，可以通过npm的方式进行安装

npm install prettier --save-dev
yarn add prettier --save-dev

3.4 安装eslint-config-prettier

安装好Prettier之后，我们还需要安装eslint-config-prettier，这是因为eslint和prettier里面的一些规则可能会存在冲突，这个时候我们就需要安装eslint-config-prettier，并且关掉所有和prettier冲突的eslint配置

npm install eslint-config-prettier --save-dev
yarn add eslint-config-prettier --save-dev

安装好eslint-config-prettier之后，接下来我们就需要关掉所有和prettier冲突的eslint配置。这里只需要在.eslintrc.js的extends中将prettier设置为最后一个extends即可，相当于用 prettier 的规则，覆盖掉 eslint:recommended 的部分规则。

extends: ["eslint:recommended", "prettier"],

3.5 安装eslint-plugin-prettier

接下来，我们还需要安装eslint-plugin-prettier，eslint-plugin-prettier的作用时是将prettier 的能力集成到eslint中，使得我们在运行eslint检查我们的代码时，能够按照prettier的规则检查代码规范性，并进行修复。

使用npm安装eslint-plugin-prettier。

npm install eslint-plugin-prettier

安装eslint-plugin-prettier后，需要对.eslintrc.js进行配置。

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

除了上面这种配置之外，我们也可以直接将上面两个步骤结合在一起，使用下面的配置就可以。

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

3.6 配置文件

Prettier和ESLint一样，支持我们通过配置文件的方式，实现自定义配置，覆盖原来的Prettier配置。

我们可以在根目录创建.prettierrc文件，.prettierrc文件支持写入YAML，JSON的配置格式，并且支持.yaml，.yml，.json和.js后缀。在平时的开发中，我们团队一般会选择创建.prettierrc.js文件，实现对prettier配置的覆盖。

在.prettierrc.js文件中，我们可以对prettier的默认配置进行修改。

module.exports = {
  // 一行最多 120 字符
  printWidth: 120,
  // 使用 2 个空格缩进
  tabWidth: 2,
  // 不使用缩进符，而使用空格
  useTabs: false,
  // 行尾需要有分号
  semi: true,
  // 使用单引号
  singleQuote: true,
  // 对象的 key 仅在必要时用引号
  quoteProps: 'as-needed',
  // jsx 不使用单引号，而使用双引号
  jsxSingleQuote: false,
  // 末尾需要有逗号
  trailingComma: 'all',
  // 大括号内的首尾需要空格
  bracketSpacing: true,
  // jsx 标签的反尖括号需要换行
  jsxBracketSameLine: false,
  // 箭头函数，只有一个参数的时候，也需要括号
  arrowParens: 'always',
  // 每个文件格式化的范围是文件的全部内容
  rangeStart: 0,
  rangeEnd: null,
  // 不需要写文件开头的 @prettier
  requirePragma: false,
  // 不需要自动在文件开头插入 @prettier
  insertPragma: false,
  // 使用默认的折行标准
  proseWrap: 'preserve',
  // 根据显示样式决定 html 要不要折行
  htmlWhitespaceSensitivity: 'css',
  // vue 文件中的 script 和 style 内不用缩进
  vueIndentScriptAndStyle: false,
  // 换行符使用 lf
  endOfLine: 'lf',
  // 格式化内嵌代码
  embeddedLanguageFormatting: 'auto',
};

3.7 忽略某些文件的格式化

Prettier和ESLint一样，也支持忽略对某些文件的格式化。如果我们存在一些不需要格式化的文件，可以在根目录创建.prettierignore文件，并且将不需要格式化的文件或目录名称写在该文件中。

dist
node_modules
.eslintignore
.prettierignore

4. VSCode插件

4.1 安装VSCode插件

配置好ESLint和Prettier之后，我们通过运行eslint命令，就可以对我们代码进行检查啦。但是，每次要手动运行命令才能检查我们的代码还是有点麻烦，有没有更简单的方式，让我们在编写代码的过程中，只要保存文件就能够对当前文件进行检查，并且自动修复一些错误呢？接下来，接下来，VSCode插件就登场啦~

首先，我们需要安装的ESLint插件，安装方法很简单，在VSCode的EXTENSIONS中找到ESLint插件，然后点击install就可以啦。

接着，我们还需要安装Prettier插件。

最后，我们也把EditorConfig for VS Code插件安装上，这个插件可以让编译器读取配置文件，并且按照配置文件里面的规定来格式化代码，有了这个插件，只要定义好一份配置文件，就算团队成员用的编译器不同，也能够输出风格统一的代码。\

4.2 配置settings.json文件

安装好插件之后，我们还需要设置VSCode的settings.json文件，实现保存代码时就自动执行ESLint检查。VSCode的setting.json设置分为工作区和用户两个级别，其中用户区会对所有项目生效，而工作区的设置只会对当前项目生效。

（1）用户区settings.json配置

点击VSCode左下角的设置按钮，选择Settings，选择以文本编辑形式打开settings.json，并且在setting.json中加入以下代码。配置完成之后，当我们保存某个文件时，就可以自动对当前文件进行ESLint检查，并且自动对一些错误进行修复啦。

{
  // #每次保存的时候自动格式化
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
},

（2）工作区settings.json配置

除了配置用户区的settings.json之外，我们也可以配置工作区的settings.json，工作区的配置只会对当前项目生效。

首先，我们需要在项目根目录创建.vscode目录，并且在该目录下创建settings.json文件。

接着，在settings.json中加入以下代码，配置完成后，当我们保存该项目中某个文件时，也会自动对该文件进行ESLint检查，并且自动修复一些问题。

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true,
  },
  "eslint.validate": ["typescript", "javascript", "vue"]
}

4.3 配置EditorConfig文件

上面在安装VSCode插件时，我们提到了要安装EditorConfig for VS Code插件，那这个插件需要怎么起作用呢？

首先，我们需要在项目根目录创建.editorconfig文件。创建完成之后，这个文件里面定义的代码规范规则会高于编译器默认的代码规范规则。

接着，我们只需要在.editorconfig文件中加入我们想要覆盖的编译器的配置，比如下面的配置定义了缩进为2个空格，那么就算编译器默认的是4个空格的缩进，最后也会按照我们的.editorconfig配置，按照2个空格进行缩进。

root = true

[*]
charset = utf-8
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true
end_of_line = auto

本文主要介绍了前端规范之CSS规范（Stylelint），将会对Stylelint的使用进行介绍，欢迎大家交流讨论~

1. Stylelint介绍及安装

1.1 什么是Stylelint

Stylelint是一个强大的，现代的代码检查工具，与ESLint类似，Stylelint能够通过定义一系列的编码风格规则帮助我们避免在样式表中出现错误。

目前在开源社区上，关于CSS Lint的解决方案主要包括了csslint、SCSS-Lint和Stylelint等几种。而由于Stylelint在技术架构上基于AST 的方式扩展CSS，除原生CSS 语法，其也支持 SCSS、Less 这类预处理器，并且也有非常多的第三方插件，因此我们团队选择了Stylelint作为CSS Lint工具。

官方文档：stylelint.io/

1.2 安装Stylelint

可以选采用npm安装Stylelint。其中，stylelint-config-standard是Stylelint的标准配置。如果想使用airbnb或prettier的规范，也可以将stylelint-config-standard改为stylelint-config-airbnb或stylelint-config-prettier。

npm install stylelint stylelint-config-standard --save-dev
yarn add stylelint stylelint-config-standard --save-dev

1.3 安装适配预处理语法的插件

如果我们项目中采用了如sass或less等css预处理器，那么可以安装适配预处理语法的插件。以sass为例，需要安装stylelint-scss插件。

npm install stylelint-scss --save-dev
yarn add stylelint-scss --save-dev

1.4 安装CSS属性排序插件

我们也可以选择安装stylelint-order插件。该插件能够强制我们按照某个顺序编写css，比如先写定位，再写盒模型，再写内容区样式，最后写CSS3相关属性，这样可以更好的保证我们代码的可读性。

npm install stylelint-order --save-dev
yarn add stylelint-order --save-dev

2. Stylelint配置

2.1 Stylelint配置方式

安装好Stylelint之后，就需要对Stylelint进行配置。Stylelint的配置方式包括了以下几种：

在package.json中添加stylelint属性并添加规则
在.stylelintrc文件中指定，.stylelintrc文件支持添加一个文件扩展名来区分 JSON，YAML 或 JS 格式，如创建.stylelintrc.json、.stylelintrc.yaml、.stylelintrc.yml或.stylelintrc.js文件
在stylelint.config.js文件中指定，该文件将会exports一个配置对象

在这里，我们选择了在项目根目录创建.stylelintrc.js来配置Stylelint。

在.stylelintrc.js文件中，我们可以指定要配置的内容，下面给出了一个配置文件的例子。

其中，该配置文件采用了stylelint-config-standard标准配置，并且添加了stylelint-order插件用于CSS属性排序，在rules中，可以指定声明块内属性的顺序，也可以自定义CSS检查规则。比如定义了color-hex-case为lower，表示CSS文件的颜色值都必须小写，否则会报错。

module.exports = {
  plugins: ['stylelint-order'],

  extends: ['stylelint-config-standard'],

  rules: {
    // 指定声明块内属性的字母顺序
    'order/properties-order': [
      'position',
      'top',
      'right',
      'bottom',
      'left',
      'z-index',
      'display',
      'float',
      'width',
      'height',
      'max-width',
      'max-height',
      'min-width',
      'min-height',
      'padding',
      'padding-top',
      'padding-right',
      'padding-bottom',
      'padding-left',
      'margin',
      'margin-top',
      'margin-right',
      'margin-bottom',
      'margin-left',
      'margin-collapse',
      'margin-top-collapse',
      'margin-right-collapse',
      'margin-bottom-collapse',
      'margin-left-collapse',
      'overflow',
      'overflow-x',
      'overflow-y',
      'clip',
      'clear',
      'font',
      'font-family',
      'font-size',
      'font-smoothing',
      'osx-font-smoothing',
      'font-style',
      'font-weight',
      'hyphens',
      'src',
      'line-height',
      'letter-spacing',
      'word-spacing',
      'color',
      'text-align',
      'text-decoration',
      'text-indent',
      'text-overflow',
      'text-rendering',
      'text-size-adjust',
      'text-shadow',
      'text-transform',
      'word-break',
      'word-wrap',
      'white-space',
      'vertical-align',
      'list-style',
      'list-style-type',
      'list-style-position',
      'list-style-image',
      'pointer-events',
      'cursor',
      'background',
      'background-attachment',
      'background-color',
      'background-image',
      'background-position',
      'background-repeat',
      'background-size',
      'border',
      'border-collapse',
      'border-top',
      'border-right',
      'border-bottom',
      'border-left',
      'border-color',
      'border-image',
      'border-top-color',
      'border-right-color',
      'border-bottom-color',
      'border-left-color',
      'border-spacing',
      'border-style',
      'border-top-style',
      'border-right-style',
      'border-bottom-style',
      'border-left-style',
      'border-width',
      'border-top-width',
      'border-right-width',
      'border-bottom-width',
      'border-left-width',
      'border-radius',
      'border-top-right-radius',
      'border-bottom-right-radius',
      'border-bottom-left-radius',
      'border-top-left-radius',
      'border-radius-topright',
      'border-radius-bottomright',
      'border-radius-bottomleft',
      'border-radius-topleft',
      'content',
      'quotes',
      'outline',
      'outline-offset',
      'opacity',
      'filter',
      'visibility',
      'size',
      'zoom',
      'transform',
      'box-align',
      'box-flex',
      'box-orient',
      'box-pack',
      'box-shadow',
      'box-sizing',
      'table-layout',
      'animation',
      'animation-delay',
      'animation-duration',
      'animation-iteration-count',
      'animation-name',
      'animation-play-state',
      'animation-timing-function',
      'animation-fill-mode',
      'transition',
      'transition-delay',
      'transition-duration',
      'transition-property',
      'transition-timing-function',
      'background-clip',
      'backface-visibility',
      'resize',
      'appearance',
      'user-select',
      'interpolation-mode',
      'direction',
      'marks',
      'page',
      'set-link-source',
      'unicode-bidi',
      'speak',
    ],

    // 颜色值要小写 
    'color-hex-case': 'lower','number-leading-zero': 'always',
  },
};

2.2 Stylelint配置项

在上面的配置文件中，我们主要定义了一个配置对象，接下来将对常用的配置项进行介绍。

（1）plugins

plugins定义了一个数组，该配置项允许我们使用第三方插件，在该数组中，需要包含“定位器”标识出你要使用的插件，一个“定位器”可以是一个 npm 模块名，一个绝对路径，或一个相对于要调用的配置文件的路径。

一旦声明了插件，在rules中需要为插件的规则添加选项，就像其他标准的规则一样。你需要查看插件的文档去了解规则的名称。

{
  "plugins": [
    “stylelint-order",
    "../special-rule.js"
  ],
  "rules": {
    "order/properties-order": [],
    "plugin/special-rule": "everything"
  }
}

（2）extends

extends定义了一个数组，该配置项允许我们extend一个已存在的配置文件(无论是你自己的还是第三方的配置)。当一个配置继承了里一个配置，它将会添加自己的属性并覆盖原有的属性。比如下面的代码，我们就extend了Stylelint的标准配置。

{
  "extends": "stylelint-config-standard",
  "rules": {
    "indentation": "tab",
    "number-leading-zero": null
  }
}

如果extends中包含多个配置项，那么数组中的每一项都优先于前一项，也就是说第二项会覆盖第一项，第三项会覆盖第一项和第二项，最后一项将覆盖其它所有项。

{
  "extends": [
    "stylelint-config-standard",
    "./myExtendableConfig"
  ],
  "rules": {
    "indentation": "tab"
  }
}

****（3）rules

rules定义了一个对象，属性名为规则名称，属性值为规则取值，它告诉Stylelint该检查什么，该怎么报错，所有的规则都是默认关闭的。我们可以通过该选项开启相应规则，进行相应的检测。所有规则必须显式的进行配置，因为没有默认值。

规则名称主要由两个部分组成，第一部分描述该规则应用于什么东西，第二部分表示该规则检查了什么。

"number-leading-zero"
// ↑          ↑
// the thing  what the rule is checking

当规则名称应用于整个样式表时只包含第二个部分：

"no-eol-whitespace"
"indentation"
//    ↑
// what the rules are checking

当规则名称不同时，规则取值也不同。我们可以将某个规则设置为null禁用该规则。

{
  "rules": {
    "at-rule-blacklist": string|[],
    "at-rule-empty-line-before": "always"|"never",
    "at-rule-name-case": "lower"|"upper",
    "block-no-empty": null,
    ...
  }
}

除了规则本身的取值之外，Stylelint还支持一些自定义配置，允许给规则传递一个数组，数组第一项是规则取值，第二项是自定义配置。

"selector-pseudo-class-no-unknown": [true, {
  "ignorePseudoClasses": ["global"]
}]

通过自定义配置，我们可以指定：

severity：错误级别，取值为”warning"或"error"，默认情况下，所有规则的错误级别都为"error"，通过defatuleServerity，可以修改错误级别的默认值

// error-level severity examples
{ "indentation": 2 }
{ "indentation": [2] }

// warning-level severity examples
{ "indentation": [2, { "severity": "warning" } ] }
{ "indentation": [2, {
    "except": ["value"],
    "severity": "warning"
  }]
}

message：当一个规则被触发时，如果你想实现一个自定义的消息，可以给规则的传递"message“作为第二选项，如果提供，将替代提供的任何标准的消息。例如，以下规则配置会使用一些自定义的消息：

  "color-hex-case": [ "lower", {
    "message": "Lowercase letters are easier to distinguish from numbers"
  } ],
  "indentation": [ 2, {
    "ignore": ["block"],
    "message": "Please use 2 spaces for indentation. Tabs make The Architect grumpy.",
    "severity": "warning"
  } ]
}

（4）processors

Processors是Stylelint的钩子函数，只能用在命令行和Node API，不适用于PostCSS插件。Processors可以使Stylelint检测非样式表文件中的CSS。例如，可以检测HTML内中标签中的CSS，Markdown文件中代码块或JavaScript中的字符串。
使用Processors的话，需要在配置中添加一个”processors“数组，包含“定位器”标识出你要使用的 processors。同上面的extends，一个“定位器”可以是一个 npm 模块名，一个绝对路径，或一个相对于要调用的配置文件的路径

{
  "processors": ["stylelint-html-processor"],
  "rules": {..}
}

如果你的processor有选项，把它们放到一个数组里，第一项是“定位器”，第二项是选项对象。

{
  "processors": [
    "stylelint-html-processor",
    [ "some-other-processor", { "optionOne": true, "optionTwo": false } ]
  ],
  "rules": {..}
}

2.3 忽略特定文件的检查

在实际的使用场景中，我们可能存在某些文件或某行代码，希望能够跳过Stylelint的检查或禁用某些规则，下面主要介绍了几种跳过Stylelint检查的方式：

（1）使用注释禁用规则

使用/* stylelint-disable */，可以在代码片段禁用所有规则或禁用特定规则。

/* stylelint-disable */
a {}
/* stylelint-enable */

/* stylelint-disable selector-no-id, declaration-no-important  */
#id {
  color: pink !important;
}
/* stylelint-enable */

使用/* stylelint-disable-line */，可以在个别行上禁用规则。

#id { /* stylelint-disable-line */
  color: pink !important; /* stylelint-disable-line declaration-no-important */
}

使用/* stylelint-disable-next-line */，可以在下一行禁用规则。

#id {
  /* stylelint-disable-next-line declaration-no-important */
  color: pink !important;
}

（2）创建.stylelintignore忽略某些文件的检查

在项目根目录创建.stylelintignore文件。

在.stylelintignore中写入需要跳过Stylelint检查的文件名称，比如下面的代码将会忽略dist，node_modules和package.json文件的Stylelint检查。

dist
node_modules
package.json

2.4 执行Stylelint检查

安装配置好Stylelint之后，我们就可以运行Stylelint命令，对指定的文件进行CSS语法检查，其中，--fix表示自动修复Stylelint错误。

运行Stylelint命令后，如果什么也没有输出，就说明我们的文件已经通过Stylelint的检查。如果输出报错信息，就说明没有通过Stylelint的检查，需要根据错误信息对代码进行修复。

// 对某个文件进行检查
stylelint "src/App.vue" --fix

// 对指定后缀名的文件进行检查
stylelint "src/*.{html,vue,css,saas,scss,less}" --fix

除了直接在命令行运行Stylelint命令方式之外，我们也可以在package.json中自定义Stylelint的启动命令。如下面代码所示，配置好package.json之后，我们通过运行npm run lint:css就能够对指定文件进行Stylelint检查。

{
"scripts": {
    "serve": "cross-env NODE_ENV=development vue-cli-service serve --mode dev",
    "serve:test": "cross-env NODE_ENV=test vue-cli-service serve --mode test",
    "serve:prod": "cross-env NODE_ENV=production vue-cli-service serve --mode prod",
    "build:dev": "cross-env NODE_ENV=production vue-cli-service build --mode dev",
    "build:test": "cross-env NODE_ENV=production vue-cli-service build --mode test",
    "build:prod": "cross-env NODE_ENV=production vue-cli-service build --mode prod",
    "lint": "vue-cli-service lint",
    "lint:css": "stylelint **/*.{vue,htm,html,css,sss,less,scss,sass} --fix"
  },
}

3. VSCode插件

3.1 安装Stylelint插件

为了让我们在编写代码的过程中，能够实时提示Stylelint错误，并且在保存文件时，能够自动对当前文件进行Stylelint检查和修复，我们可以在VSCode中安装Stylelint插件。

在VSCode的EXTENSIONS中找到Stylelint插件，点击install就可以安装Stylelint插件。

3.2 配置settings.json文件

安装好Stylelint插件之后，我们还需要配置VSCode的settings.json文件，让我们的代码在保存时，就能够按照规范对CSS样式进行检查及自动fix。VSCode的settings.json设置分为工作区和用户区两个级别。其中，用户区的设置会对所有项目生效，工作区的设置只能对当前项目生效。

（1）用户区settings.json配置

点击VSCode左下角的设置按钮，选择Settings，并且选择以文本编辑的方式打开settings.json，在settings.json中加入以下代码。

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {"source.fixAll.stylelint": true // 保存时是否自动 stylelint 修复
  },
}

（2）工作区settings.json配置

在项目根目录创建.vscode目录，并且在该目录下创建settings.json文件。

在settings.json中加入以下代码

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.stylelint": true // 保存时是否自动 stylelint 修复
  }
}

配置好用户区或工作区的settings.json后，当我们修改了某个文件的CSS代码，并且保存时，就会发现能够对当前文件自动进行stylelint检查和修复了。本文主要介绍了前端规范之Git工作流规范（Husky + Commitlint + Lint-staged），将会对Husky、Commitlint和Lint-staged的使用进行介绍，欢迎大家交流讨论~

1. 背景

在前面的几篇文章中，我们已经介绍了如何在项目中安装并配置ESLint、Prettier、Stylelint和Commitizen。有了这些工具，可以很好的帮助我们格式化代码并提示错误。

然而，有些同学可能会把ESLint、Stylelint或Commitizen提示的错误忽视不见，直接将代码提交到代码仓库中。这样做的话，那么其他同学在pull代码并diff代码时可能会出现大段代码标红，同时在进行CI时又可能因为代码风格或规范问题被打回重改。

那么，有没有一种方法，让大家在提交代码时需要确保本地的代码或Commit Message已经通过检查才能够push到代码仓库，从而更好的保障代码质量呢？接下来，将会介绍如何使用Husky + Commintlint + Lint-staged打造规范的Git检查工作流，确保我们的代码只有符合规范才能提交到代码仓库。

2. Husky

首先，先来介绍一下Husky的安装和相关配置。

2.1 什么是git hook

在介绍Husky之前，我们先来看什么是git hook，也就是常说的Git钩子。

和其它版本控制系统一样，Git能在特定的重要动作发生时触发自定义脚本。有两组这样的钩子：客户端的和服务器端的。客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。你可以随心所欲地运用这些钩子。

其中，客户端钩子我们可能用的比较多，客户端钩子通常包括了提交工作流钩子、电子邮件工作流钩子和其它钩子。这些钩子通常存储在项目的.git/hooks目录下，我们需要关注的主要是提交工作流钩子。提交工作流钩子主要包括了以下四种：

pre-commit：该钩子在键入提交信息前运行。它用于检查即将提交的快照。如果该钩子以非零值退出，Git 将放弃此次提交，你可以利用该钩子，来检查代码风格是否一致。
prepare-commit-msg：该钩子在启动提交信息编辑器之前，默认信息被创建之后运行。它允许你编辑提交者所看到的默认信息。
commit-msg：该钩子接收一个参数，此参数存有当前提交信息的临时文件的路径。如果该钩子脚本以非零值退出，Git 将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。
post-commit：该钩子一般用于通知之类的事情。\

在上面的钩子中，我们需要关注pre-commit和commit-msg钩子。

2.2 什么是husky

husky是常见的git hook工具，使用husky可以挂载Git钩子，当我们本地进行git commit或git push等操作前，能够执行其它一些操作，比如进行ESLint检查，如果不通过，就不允许commit或push。

2.3 安装husky

安装husky，可以使用npm进行安装。

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

2.4 配置husky

安装好husky之后，还需要对husky进行配置。不同版本的husky配置方法有些不同，这里主要对4.3.8版本的配置进行介绍。

首先，我们需要先安装配置好ESLint或Stylelint，并且在package.json中加入以下代码。

"husky": {
  "hooks": {
    "pre-commit": "eslint src/**/*.{js,jsx,ts,tsx}",
  }
 }

接着，当我们执行git commit时，就会触发pre-commit钩子，并且执行对应命令，这里将会指定目录下的文件进行ESLint检查，如果ESLint检查不通过，是无法进行commit的。

如果ESLint检查通过，就可以正常进行commit。

在安装并配置好husky之后，如果发现在commit时不能触发pre-commit，可以试着重新安装husky，并且重启VSCode。

2.5 只使用husky的问题

使用husky虽然能够帮助我们在commit或push前执行一些指令，但是如果只使用husky，仍然存在下面这些问题：

在某次提交时，我们只修改了某个文件，但是只使用husky会把所有的文件都运行一遍Lint检查，时间成本太高。此外，有些项目会在中途才加上husky，但是在commit时husky也会对其它未修改的历史代码进行检查，可能会一下子报了很多错误，这个时候我们更希望只对当前修改过的文件进行检查，而不是对项目中的代码都进行检查。
husky的钩子只能执行一个指令，但是有时候我们希望能够在git commit之前执行多个指令，比如执行ESLint、Stylelint或Commitlint等操作。

为了解决上面的问题，就需要结合Lint-staged一起使用。

3. Lint-staged

接下来，将会对Lint-staged的安装和配置进行介绍。

3.1 什么是Lint-staged

Lint-staged可以在git staged阶段的文件上执行Linters，简单说就是当我们运行ESlint或Stylelint命令时，可以通过设置指定只检查我们通过git add添加到暂存区的文件，可以避免我们每次检查都把整个项目的代码都检查一遍，从而提高效率。

其次，Lint-staged允许指定不同类型后缀文件执行不同指令的操作，并且可以按步骤再额外执行一些其它shell指令。

3.2 安装Lint-staged

安装Lint-staged，可以使用npm进行安装。

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

3.3 配置Lint-staged

安装好了Lint-staged之后，就需要配置Lint-staged。我们可以在package.json中加入以下代码，这里需要先安装配置好husky，ESLint和Stylelint。

"husky": {
  "hooks": {
    "pre-commit": "lint-staged",
  }
},
"lint-staged": {
  "*.vue": [
    "eslint --fix",
    "stylelint --fix",
    "git add"
  ],
  "*.{js,jsx,ts,tsx}": [
    "eslint --fix",
    "git add"
  ],
  "*.{htm,html,css,sss,less,scss,sass}": [
    "stylelint --fix",
    "git add"
  ]
}

当我们执行git commit时，就会触发husky的pre-commit钩子，调用lint-staged命令。而lint-staged包含了对*.vue，.{js,jsx,ts,tsx}，.{htm,html,css,sss,less,scss,sass}类型文件的操作。以*.vue为例，当匹配到后缀名为.vue的文件时，就会分别执行以下操作：

首先会执行eslint --fix命令，对.vue文件执行ESLint检查，并且自动修复一些JS格式问题
接着会执行stylelint --fix命令，对.vue文件的CSS执行Stylelint检查，并且自动修复一些CSS格式问题
最后，若前面的指令都执行通过，那么将通过git add命令将文件重新加入到本地的git commit中，如果没有执行通过，那么将不能commit

4. Commitlint

除了在commit前对JS和CSS执行ESLint和Stylelint检查之外，也可以对Commit Message进行检查。接下来，将会介绍Commitlint的安装和配置方法。

4.1 什么是Commitlint

在使用Git提交代码时，通常都需要填写提交说明，也就是Commit Message。在前面的文章中，已经介绍了如何使用Commitizen或可视化工具编写符合规范的Commit Message。然而有些同学可能还是会使用git commit方式提交一些不符合规范的Commit Message。为了禁止不符合规范的Commit Message的提交，我们就需要采用一些工具，只有当开发者编写了符合规范的Commit Message才能够进行commit。而Commitlint就是这样一种工具，通过结合husky一起使用，可以在开发者进行commit前就对Commit Message进行检查，只有符合规范，才能够进行commit。\

4.2 安装Commitlint

使用npm安装Commitlint相关依赖包。

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

4.3 配置Commitlint

安装好Commitlint之后，就需要配置Commitlint，可以在根目录创建commitlint.config.js文件进行配置。

在comminlint.config.js中加入以下代码，表示使用config-conventional规范对提交说明进行检查。具体的规范配置可以查看：github.com/conventiona…

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

接下来，需要在package.json中加入commit-msg钩子。

"husky": {
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

配置好了之后，当我们进行git commit时，就会触发commit-msg钩子，执行commintlint命令，并且读取commitlint.config.js中的规则对我们的提交说明进行检查，如果校验不通过，将不能提交。

5. Git检查工作流

在介绍完Husky，Commitlint和Lint-staged之后，接下来，我们就可以将这几个工具结合起来，打造完整的Git检查工作流。下面给出了一份示例代码，其中，该项目采用了Vue-cli进行构建，下面是该项目对应的package.json文件。

{
  "name": "test",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "lint": "vue-cli-service lint",
  },
  "dependencies": {
    "core-js": "^3.6.5",
    "vue": "^2.6.11",
    "vue-router": "^3.2.0",
    "vuex": "^3.4.0"
  },
  "devDependencies": {
    "@commitlint/cli": "^12.1.4",
    "@commitlint/config-conventional": "^12.1.4","@vue/cli-plugin-babel": "^4.5.0",
    "@vue/cli-plugin-eslint": "^4.5.0",
    "@vue/cli-service": "^4.5.0",
    "@vue/eslint-config-prettier": "^6.0.0",
    "babel-eslint": "^10.1.0",
    "eslint": "^6.7.2",
    "eslint-plugin-prettier": "^3.3.1",
    "eslint-plugin-vue": "^6.2.2",
    "husky": "^4.3.8",
    "less": "^3.0.4",
    "less-loader": "^5.0.0",
    "lint-staged": "^11.0.0",
    "prettier": "^2.2.1",
    "stylelint": "^13.13.1",
    "stylelint-config-prettier": "^8.0.2","stylelint-config-standard": "^22.0.0",
    "stylelint-order": "^4.1.0",
    "stylelint-webpack-plugin": "^2.2.2",
    "vue-template-compiler": "^2.6.11"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
  "lint-staged": {
    "*.vue": [
      "vue-cli-service lint",
      "stylelint --fix",
      "git add"
    ],
    "*.{js,jsx,ts,tsx}": [
      "vue-cli-service lint"
      "git add"
    ],
    "*.{htm,html,css,sss,less,scss,saas}":[
      "stylelint --fix"
      "git add"
    ]
  }
}

配置好package.json之后，当我们进行git commit提交时，首先将会触发pre-commit钩子，调用lint-staged命令，并且会对不同后缀的文件执行不同的检查。接着，还将会触发commit-msg钩子，调用commitlint对我们的提交说明进行检查。如果其中一个无法通过检查，将无法提交。

当校验通过时，就可以放心的将代码提交到代码仓库中，而不用再担心代码风格等问题啦~ 本文主要介绍了前端规范之Git提交规范（Commitizen），将会对Commitizen的使用进行介绍，欢迎大家交流讨论~

1. 背景

Git是目前世界上最先进的分布式版本控制系统，在我们平时的项目开发中已经广泛使用。而当我们使用Git提交代码时，都需要写Commit Message提交说明才能够正常提交。

然而，我们平时在编写提交说明时，通常会直接填写如"fix"或"bug"等不规范的说明，不规范的提交说明很难让人明白这次代码提交究竟是为了什么。而在工作中，一份清晰简介规范的Commit Message能让后续代码审查、信息查找、版本回退都更加高效可靠。因此我们需要一些工具来约束开发者编写符合规范的提交说明。

2. 提交规范

那么，什么样的提交说明才能符合规范的说明呢？不同的团队可以制定不同的规范，当然，我们也可以直接使用目前流行的规范，比如Angular Git Commit Guidelines。接下来将会对目前流行的Angular提交规范进行介绍。

2.1 提交格式

符合规范的Commit Message的提交格式如下，包含了页眉（header）、正文（body）和页脚（footer）三部分。其中，header是必须的，body和footer可以忽略。

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

2.2 页眉设置

页眉（header）通常只有一行，包括了提交类型（type）、作用域（scope）和主题（subject）。其中，type和subject是必须的，scope是可选的。

****2.2.1 提交类型

****提交类型（type）用于说明此次提交的类型，需要指定为下面其中一个：

2.2.2 作用域

作用域（scope）表示此次提交影响的范围。比如可以取值api，表明只影响了接口。\

2.2.3 主题

****主题（subject）描述是简短的一句话，简单说明此次提交的内容。

2.3 正文和页脚

正文（body）和页眉（footer）这两部分不是必须的。

如果是破坏性的变更，那就必须在提交的正文或脚注加以展示。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，紧跟冒号和空格。脚注必须只包含 BREAKING CHANGE、外部链接、issue 引用和其它元数据信息。例如修改了提交的流程，依赖了一些包，可以在正文写上：BREANKING CHANGE：需要重新npm install，使用npm run cm代替git commit。

下面给出了一个Commit Message例子，该例子中包含了header和body。

chore: 引入commitizen

BREANKING CHANGE：需要重新npm install，使用npm run cm代替git commit

当然，在平时的提交中，我们也可以只包含header，比如我们修改了登录页面的某个功能，那么可以这样写Commit Message。

feat(登录）：添加登录接口

3. Commitizen

虽然有了规范，但是还是无法保证每个人都能够遵守相应的规范，因此就需要使用一些工具来保证大家都能够提交符合规范的Commit Message。常用的工具包括了可视化工具和信息交互工具，其中Commitizen是常用的Commitizen工具，接下来将会先介绍Commitizen的使用方法。

3.1 什么是Commitizen

Commitizen是一个撰写符合上面Commit Message标准的一款工具，可以帮助开发者提交符合规范的Commit Message。

3.2 安装Commitizen

可以使用npm安装Commitizen。其中，cz-conventional-changelog是本地适配器。

npm install commitizen cz-conventional-changelog --save-dev
yarn add commitizen cz-conventional-changelog --save-dev

3.3 配置Commitizen

安装好Commitizen之后，就需要配置Commitizen，我们需要在package.json中加入以下代码。其中，需要增加一个script，使得我们可以通过执行npm run cm来代替git commit，而path为cz-conventional-changelog包相对于项目根目录的路径。

”script": {
  "cm: "git-cz"
},
"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  }
}

配置完成之后，我们就可以通过执行npm run cm来代替git commit，接着只需要安装提示，完成header、body和footer的编写，就能够编写出符合规范的Commit Message。

4. 可视化提交工具

除了使用Commitizen信息交互工具来帮助我们规范Commit Message之外，我们也可以使用编译器自带的可视化提交工具。接下来，将会介绍VSCode可视化提交工具的使用方法。

在VSCode的EXTENSIONS中找到git-commit-plugin插件，点击install进行安装。

安装完成之后，可以通过git add添加要提交的文件，接着，在Source Control点击show git commit template图标，开始编写Commit Message信息。

接下来只需要按照指引进行Commit Message的编写。

当编写完成之后，可以得到符合规范的Commit Message，这个时候就可以放心将Commit Message及所修改的文件进行提交啦。

前端规范小总结

1. 统一代码风格的重要性

1.1 为什么要统一代码风格

1.2 如何统一代码风格

2. ESLint

2.1 什么是ESLint

2.2 安装ESLint

2.3 ESLint配置方式

2.4 ESLint配置项解析

2.5 运行ESLint检查文件

2.6 跳过ESLint的检查

3. Prettier

3.1 什么是Prettier

3.2 为什么要用Prettier

3.3 安装Prettier

3.4 安装eslint-config-prettier

3.5 安装eslint-plugin-prettier

3.6 配置文件

3.7 忽略某些文件的格式化

4. VSCode插件

4.1 安装VSCode插件

4.2 配置settings.json文件

4.3 配置EditorConfig文件

1. Stylelint介绍及安装

1.1 什么是Stylelint

1.2 安装Stylelint

1.3 安装适配预处理语法的插件

1.4 安装CSS属性排序插件

2. Stylelint配置

2.1 Stylelint配置方式

2.2 Stylelint配置项

2.3 忽略特定文件的检查

2.4 执行Stylelint检查

3. VSCode插件

3.1 安装Stylelint插件

3.2 配置settings.json文件

1. 背景

2. Husky

2.1 什么是git hook

2.2 什么是husky

2.3 安装husky

2.4 配置husky

2.5 只使用husky的问题

3. Lint-staged

3.1 什么是Lint-staged

3.2 安装Lint-staged

3.3 配置Lint-staged

4. Commitlint

4.1 什么是Commitlint

4.2 安装Commitlint

4.3 配置Commitlint

5. Git检查工作流

1. 背景

2. 提交规范

2.1 提交格式

2.2 页眉设置

2.3 正文和页脚

3. Commitizen

3.1 什么是Commitizen

3.2 安装Commitizen

3.3 配置Commitizen

4. 可视化提交工具