写在最前

最近在初始化工程，为了规范代码风格和提交风格，在代码提交的时候利用git hooks对代码做了一些处理。在此过程中学到的东西做一下总结

一、.git

.git文件夹是git init后在当前目录生成的一个管理git仓库的文件夹，这里包含所有git操作所需要的东西。

git的命令commit、push、rebase等等，这些命令主要是在执行.git文件夹中的东西。

这个 .git 文件夹是隐藏的。需要显示隐藏文件夹才能看到。

1.Git Hooks

挂钩都被存储在 .git 目录下的 hooks 子目录中，即项目中的 .git/hooks

git 初始化的时候生成的默认钩子，已包含了大部分可以使用的钩子，但是有 .sample 拓展名，防止它们默认被执行。

启用对应钩子，你只需要去掉 .sample 拓展名。

commit操作有 4个挂钩被用来处理提交的过程，他们的触发时间顺序如下：
pre-commit、prepare-commit-msg、commit-msg、post-commit

钩子执行顺序是有先后的

• 前置（pre）钩子，在动作完成前调用
• 后置（post）钩子，在动作完成后执行

当钩子在非零状态下退出，git操作就会停止。

我们想在提交代码的时候对代码做检查，需要在钩子里写入指令，执行git操作前先运行钩子里的指令，调用eslint检查代码，如果代码不符合规范就非零退出，git操作就会停止，从而达到我们的目的。

但是手动修改hooks会比较麻烦，我们可以通过husky来创建钩子进行管理

二、利用husky构建钩子

1.husky

https://github.com/typicode/husky

npm install --save-dev husky

改写了.git/hooks 目录中的文件，只需在package.json 中配置对应钩子要执行的脚本。在 Git 操作时触发；

package.json

  "husky": {

    "hooks": {

      "pre-commit": "lint-staged",

      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"

    }

  },

这段配置做了两个事情：
在pre-commit的时候触发lint-staged
在commit-msg的时候触发commitlint

下面来详细讲讲lint-staged、commitlint这两个包

2.Lint-staged

https://github.com/okonet/lint-staged
从这个包名，就可以看出，Run linters on git staged files，只针对本次提交所改动的文件进行处理。

安装：

npm install --save-dev lint-staged

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

package.json中

  "lint-staged": {

    "*.{js,jsx}": [

      "eslint --fix",

      "git add"

    ]

  }

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

3.eslint

如果同一目录中有多个配置文件，则ESLint将仅使用一个。优先顺序为：

1. .eslintrc.js
2. .eslintrc.cjs
3. .eslintrc.yaml
4. .eslintrc.yml
5. .eslintrc.json
6. .eslintrc
7. package.json

具体的配置在这里不再赘述，按照自己的代码需要配置即可

4.commitlint

https://github.com/conventional-changelog/commitlint

用来设置代码提交规范，方便团队协作和快速定位问题

安装：

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

配置文件commitlint.config.js，当然也可以是 .commitlintrc.js:

module.exports = {

    extends: ['@commitlint/config-conventional'],

    rules: {

        'type-enum': [

            2,

            'always',

            [

            'feat', // 新功能（feature）

            'fix', // 修补bug

            'docs', // 文档（documentation）

            'style', // 格式（不影响代码运行的变动）

            'refactor', // 重构（即不是新增功能，也不是修改bug的代码变动）

            'test', // 增加测试

            'revert', // 回滚

            'config', // 构建过程或辅助工具的变动

            'chore', // 其他改动

            ],

        ]

    }

}

5.钩子工作流程说明

当开发者执行 git add 操作将代码提交到暂存区后，再执行 git commit 操作时：

1. 由于安装husky后其在.git/hooks中写入了pre-commit钩子，该钩子在 git commit 执行时被触发，执行npm run precommit脚本（即lint-staged命令）；
2. lint-staged的配置，就是利用linters对暂存区的文件路径应用过滤规则，匹配的文件将执行后面配置的任务，这里的任务就是调用项目中的eslint指令检查文件，如果报错则先自动修复--fix，最后把没有问题的代码加入暂存区git add。
3. 如果最终还有报错，则流程终止，无法执行 commit 操作。

操作过程中遇到的一些问题：
husky v4 需要node>=10，而目前在用的node版本还是8，此时无法触发钩子
因此退到
"husky": "^3.1.0"
"lint-staged": "^9.5.0",
此时需要最低node版本是v8.12.0

三、EditorConfig

什么是EditorConfig？官方介绍：帮助开发人员定义和维护一致性开发风格(coding style)。它可以让代码在各种编辑器和IDE中保持风格一致，当然也可以让不同的队员写一致风格的代码

1.使用EditorConfig

使用EditorConfig很简单，在项目根目录放置一个. editorconfig文件

root = true



[*]

charset = utf-8

indent_style = space

indent_size = 4

end_of_line = lf

insert_final_newline = true

trim_trailing_whitespace = true



[*.md]

trim_trailing_whitespace = false

1. indent_style：tab为hard-tabs，space为soft-tabs。
2. indent_size：设置整数表示规定每级缩进的列数和soft-tabs的宽度（译注：空格数）。如果设定为tab，则会使用tab_width的值（如果已指定）。
3. tab_width：设置整数用于指定替代tab的列数。默认值就是indent_size的值，一般无需指定。
4. end_of_line：定义换行符，支持lf、cr和crlf。
5. charset：编码格式，支持latin1、utf-8、utf-8-bom、utf-16be和utf-16le，不建议使用uft-8-bom。
6. trim_trailing_whitespace：设为true表示会除去换行行首的任意空白字符，false反之。
7. insert_final_newline：设为true表明使文件以一个空白行结尾，false反之。
8. root：表明是最顶层的配置文件，发现设为true时，才会停止查找.editorconfig文件

按照上面配置即可，IDE中需要开启相应EditorConfig插件，不安装是没有效的！！！！

以vscode为例，需要安装：

EditorConfig for VS Code插件

四、Prettier

代码格式化工具

1.有了 ESLint ，为什么还要Prettier 呢？

• eslint的主要校验常见的语法和代码风格错误（未使用变量、三等号、全局变量声明等问题）
• Prettier 只是代码格式的校验（并格式化代码）。例如单行代码长度、tab长度、空格、逗号表达式等问题。

配合ESLint检测代码风格主要有一下两个插件：

eslint-plugin-prettier 和 eslint-config-prettier

2.eslint-plugin-prettier

eslint-plugin-prettier 会对比格式化前和用 Prettier 格式化后的代码，有不一致的地方就会报错提示

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

3.eslint-config-prettier

如果你曾经尝试过将 Prettier 和 ESLint 放在一起运行，那么可能会遇到规则冲突。

这个插件是如果eslint的规则和prettier的规则发生冲突的时候（主要是不必要的冲突），例如eslint 限制了必须单引号，prettier也限制了必须单引号，那么如果用 eslint 驱动 prettier 来做代码检查的话，就会提示2种报错，虽然他们都指向同一种代码错误，这个时候就会由这个插件来关闭掉额外的报错。

实现 prettier 规则对 eslint 规则的覆盖。

使用的时候需要确保，这个配置在extends的最后一项。

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

4.同时设置eslint-plugin-prettier 和 eslint-config-prettier

如果你同时使用了上述的两种配置，那么你可以通过如下方式，简化你的配置。（省去了上面两个单独的配置）

在.eslintrc文件中加入以下配置

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

这段代码有三个作用

• 继承prettier的config规则
• 开启rules的 "prettier/prettier": "error"
• eslint fix的同时执行prettier格式化

参考:

利用 git 钩子做代码提交前的检查
前端代码风格自动化系列（三）之Lint-staged
一招让你成为前端大牛
prettier浅出
使用ESLint+Prettier来统一前端代码风格
eslint+husky+prettier+lint-staged提升前端应用质量