前端工程化之代码提交规范Eslint + Prettier + Husky + Commitlint+ lint-staged(React篇)

一、背景

一套统一的代码规范有助于促进团队合作，提高代码review的效率，减少BUG数，便于后期代码维护。笔者就目前前端主流的团队代码规范方案进行了探索和实践，以下就是我在实践中的流程记录。

二、Eslint代码检测工具

ESLint 是一个开源的 JavaScript 代码检查工具,从2013年问世后到现在已经成为代码检查工具中的翘楚。

• 项目中集成 通过命令行快速集成：

npm init @eslint/config

命令执行中会要求进行以下选项： 大家根据项目实际情况进行选择，初始化完成后会在项目根目录下创建.eslintrc.js文件：

module.exports = {    "env": {        "browser": true,        "es2021": true    },    "extends": [        "eslint:recommended",        "plugin:react/recommended",        "plugin:@typescript-eslint/recommended"    ],    "overrides": [    ],    "parser": "@typescript-eslint/parser",    "parserOptions": {        "ecmaVersion": "latest",        "sourceType": "module"    },    "plugins": [        "react",        "@typescript-eslint"    ],    "rules": {    }

此时在package.json文件内的script属性下添加eslint脚本检测命令：

"lint": "eslint --ext .js --ext .jsx src",   

运行npm run lint就可以对src目录下的js以及jsx文件进行代码检测，结果会在命令后界面内进行提示：

也可以在lint脚本内添加--fix进行自动修复报错，有些报错还是需要手动修复：

  "lint": "eslint --ext .js --ext .jsx --fix src"

注意:根目录下添加.eslintignore文件可以配置不需要经过eslint的文件:

build/*
config/*
docs/*
node_modules/*
public/*
scripts/*
mock/*
*.css
package.json
.eslintrc.js

• 添加Airbnb代码规范

eslint自带的代码规范还不足以满足大家的需求，于是就有了各家大厂的规范，包括有Airbnb、阿里、百度等，这里我们选用国际通用的Airbnb的代码规范。首先命令后快速安装： npm i eslint-config-airbnb -D 安装成功后在.eslintrc.js文件的extends属性加入airbnb:

"extends": [   
     "eslint:recommended",    
     "plugin:react/recommended",   
     "airbnb",     
     "plugin:@typescript-eslint/recommended" 
   ],

Airbnb的规范可以自行百度， 配置完成后最好重新启动VScode让这些配置生效. 自此eslint的代码规范就已经配置好了，如果需要自己手动配置检测规则可以在.eslintrc.js内的rules属性内添加规则：

"rules": {

"generator-star-spacing": [0],
"consistent-return": [0],
"react/forbid-prop-types": [0]
}

• VScode内安装Eslint插件 为了方便在代码里自动提示代码错误需要去VScode的插件市场安装ESlint插件：

安装成功后重新启动VSCode就可以在代码里看到错误提示，红色波浪线：

通过在vscode的settings.json内部添加以下配置就可以实现保存后自动进行eslint的修复:

       "source.fixAll.eslint": true
    

注明：ESlint插件生效进行代码内错误提示还需要配合在项目里npm安装eslint包

三、Prettier代码风格工具

Prettier使用作代码格式化的工具，尽管eslint自带了部分代码格式化功能，但是远不如专业的格式化工具好用，eslint搭配Prettier使用来达到最优的代码格式化效果。

• 项目安装 npm i prettier eslint-config-prettier eslint-plugin-prettier -D

其中eslint-config-prettier和 eslint-plugin-prettier两个插件是为了兼容eslint用，安装成功后在.eslintrc.js里的extends下添加plugin:prettier/recommended ：

"extends": [    
    "airbnb",        
    "airbnb/hooks",     
    "eslint:recommended",   
    "plugin:react/recommended",      
    "plugin:@typescript-eslint/recommended",    
    'plugin:prettier/recommended',         
  ]

• 根目录下添加prettier配置文件.prettierrc.json:

{

"printWidth": 300,

"tabWidth": 2,

"semi": true,//分号

"singleQuote":true,//单引号

"jsxSingleQuote": true 

}

可以通过添加文件.prettierignore来忽略不需要做格式化的文件。

• VScode安装Prettier插件进行保存自动格式化代码：

到此eslint和preitter的配置全部完成。

四、git规范

git hook的钩子有很多，在代码提交流程里最重要的是pre-commit和commit-msg两个钩子。

• 安装Husky进行git hook钩子的控制

首先在项目内执行： npm install husky --save-dev

安装成功后package.json的script内添加脚本：

 "prepare": "husky install"

接着执行npm run prepare，安装成功后在项目根目录下会出现.husk文件夹：

• 使用husk命令创建pre-commit和commit-ms钩子：

  1.pre-commit

  • 执行git commit命令时会先执行pre-commit这个脚本,运行：

  `npx husky add .husky/pre-commit "npm run test"`  
  

  执行成功后会在.husky/目录下新增了一个名为pre-commit的shell脚本：

  #!/bin/sh
  . "$(dirname "$0")/_/husky.sh"
  
   npm run  test
  
  

  注意：如果是在VSCode内部的powsershell终端执行上面的命令，需要将npm run test改成npm-run-test

  • lint-stage 在提交代码之前运行代码检测更有意义。通过这样做，可以确保没有错误进入远程仓库。但是在整个项目中运行检测过程是缓慢的，检测结果可能是无关的。最终，我们只希望检查将要提交的文件，也就是放入暂存区的代码,lint-staged就是用来控制只检测暂存区代码的工具库。

    1. 项目内安装lint-sage:

     npm install --save-dev lint-staged
    

    1. 在package.json内添加以下属性：

       "lint-staged": {
       "src/**/*.{js,jsx,ts,tsx,json,md}": 
       [
       "eslint --fix",
       "prettier --write src/"
       ]
       }
       

    2. .husky/pre-commit 文件内npm run test更新为 npx lint-stage ` :

       #!/usr/bin/env sh
       . "$(dirname "$0")/_/husky.sh"
       npx lint-staged
       

  以上配置最终的流程是执行git commit时会对暂存区内src目录下的(js,jsx,ts,tsx,json,md)文件进行eslint检测和代码格式化，如果检测不通过就不能提交成功,执行git commit命令提交代码：

  

  1. commit-msg commitlint 搭配 husky 的 commit message 钩子后，每次commit的时候都会由commitlint对commit message进行一次校验，若不符合规则会 commit 失败，并提示相应报错信息。

     • 安装 commitlint

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

     安装成功后在项目根目录下创建commitlint.config.js，内容如下：

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

     • husky创建commit-msg的git hook 执行npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

       运行完该命令后我们会看到.husky/目录下新增了一个名为commit-msg的shell脚本,commit-msg脚本内容如下：

       

       #!/usr/bin/env sh. "$(dirname -- "$0")/_/husky.sh"
       npx --no-install commitlint --edit ""
       
       

       手动将npx那一行的内容替换为npx --no -- commitlint --edit $1,最终如下：

       #!/usr/bin/env sh. "$(dirname -- "$0")/_/husky.sh"
       npx --no -- commitlint --edit $1
       

     以上commit-msg钩子就配置完成了，此时去尝试执行git commit命令，commit msg不符合规范就会报错：

     

     • commitlint规范

     type(scope?): subject
     body?
     footer?
     

     其中的换行和空格符号都是必须的，其中type和subject是必须填写的:

     type: commit 的类型 subject: commit 的概述

     • feat: 新功能、新特性
     • fix: 修改 bug
     • perf: 更改代码，以提高性能
     • refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
     • docs: 文档修改
     • style: 代码格式修改, 注意不是 css 修改（例如分号修改）
     • test: 测试用例新增、修改
     • build: 影响项目构建或依赖项修改
     • revert: 恢复上一次提交
     • ci: 持续集成相关文件修改
     • chore: 其他修改（不在上述类型中的修改）
     • release: 发布新版本
     • workflow: 工作流相关文件修改

     scope: commit 影响的范围, 比如: route, component, utils, build… body: commit 具体修改内容, 可以分为多行. footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接. 举例提交格式：

      git commit -m 'fix(login): 修复登录的bug'
     
     

五、流程总结

以上就是代码规范提交的所有操作步骤，安装步骤如下: 1、安装eslint和preitter 2、安装husky 3、安装lint-stage 4、安装commitlint 5、husk安装pre-commit和commit-msg钩子 当进行代码编写时就能在代码不符合规范的地方进行报错提示和一键修复，在进行代码提交时会对提交文字信息和暂存区内的代码进行代码检测和格式化，检测没通过就不能成功提交代码，整体这一套流程能规避许多代码风险，统一团队代码风格，对于新项目强力推荐加上这部分控制。