eslint+prettier+husky+lint-staged 统一前端代码规范

eslint+prettier+husky+lint-staged 统一前端代码规范

遵循编码规范和使用语法检测，能够很好的提升代码的可读性，可维护性，并有效的减小一些编码错误。

一、终极目标

团队中的全部开发人员用一套代码规范规则，而且无需咱们花太大的精力去为了格式而格式。但愿有一套自动化工具，帮咱们检测代码是否规范，若是不规范，则自动可以帮咱们按照既定规范格式化。

实现这一目标需解决的问题：

一、代码规范落地难：面对开发规范常常面临的现状是很难落地，老是“拆东墙补西墙”，归根结底在于须要工具去强行保证代码必须通过代码开发规范的扫描；

二、低质量代码带入线上应用：在开发现状中开发人员能够简单的执行git push操做将本地代码带入远程分支上，若是代码质量低下就很容易对线上应用质量埋下隐患，最好的方式本地进行commit的时候，最起码须要保证当前代码可以知足团队制定的开发规范，若是不经过，commit都没法成功，这样可以从最源头保证代码质量；

三、代码格式难统一：现状团队开发成员代码格式都有很大的不一样，有些人字符串喜欢用双引号，有的人喜欢使用单引号等等问题，若是代码格式化问题不统一，互相查看其它人代码很累，甚至代码格式错乱，严重影响代码可读性，无疑也增长了团队内的沟通成本，针对这样状况，须要一种工具可以保证团队内代码的格式是一致；

四、代码质量文化难落地：过引入代码质量工具，在开发过程当中可以时刻对自身代码质量进行约束，逐渐培养自身对代码质量有“洁癖”的开发观念，同时也会成为团队乃至自身对质量文化落地的一个抓手；

面对以上问题，eslint+prettier+husky+lint-staged 这几个工具可以有效解决上述问题。

二、eslint 配置

ESLint 是一个Javascript Linter，帮助咱们规范代码质量，提升团队开发效率。

避免代码错误、写出最佳实践、规范变量使用方式、规范代码格式；

社区比较知名的代码规范，eslint 配合这些代码规范，可以检测出代码潜在问题，从而提升代码质量。

官方提供了3种规范：

eslint-config-google：Google标准

eslint-config-airbnb：Airbnb标准,它依赖eslint, eslint-plugin-import, eslint-plugin-react, and eslint-plugin-jsx-a11y等插件，而且对各个插件的版本有所要求

eslint-config-standard：Standard标准，它是一些前端工程师自定的标准，

目前来看，公认的最好的标准是Airbnb标准。

2.1 默认配置

使用 Create React App 建立的 React 应用，默认安装了ESLint依赖，package.json文件中的 eslintConfig 属性只提供了用于发现常见错误的最小规则集。

 "eslintConfig": {
        "extends": "react-app"
   }

2.2 自定义配置

2.2.1 在根目录下建立 .eslintrc.json 文件，完成一些基础配置，代码以下：

{
    // env：你的脚本将要运行在什么环境中
    "env": {
        "browser": true,
        "es6": true,
        "jquery":true
   },
    // globals：脚本在执行期间访问的额外的全局变量
    "globals": {
        "$": true,
        "process": true,
        "__dirname": true
   },
    // 指定ESLint使用的解析器，默认是Espree
    "parser": "babel-eslint",
     // 指定想要支持的 JavaScript 语言选项
    "parserOptions": {
        "ecmaFeatures": {
            "experimentalObjectRestSpread": true,
            "jsx": true,
            "modules": true
       },
        "sourceType": "module",
        "ecmaVersion": 7
   },
     //让eslint支持 JSX start
    "plugins": ["react"],
    // 继承已启用的规则
    "extends": ["eslint:recommended"],
    // 启用的规则及其各自的错误级别。自定义启用或关闭一些规则
    "rules": {
        "react/jsx-uses-react": 1,
        "no-unused-vars": 0, //变量声明未被使用校验
        "no-empty": 0,
        "quotes": 0, //单引号
        "no-console": 0 //不由用console
   }
}

想具体了解各个配置什么意思的，请参考官网：http://eslint.cn/docs/user-guide/configuring

2.2.2 配置完成，测试效果

完成上述配置以后，只会影响编辑器和 IDE 检测与规则不符的代码（好比在vscode中与规则不符的代码有红色的下划波浪线），不会在控制台和浏览器中出现相关提示。

2.3 扩展 ESLint 配置

因咱们项目使用react-app-rewired 对 Create React App 进行了自定义配置，因此须要修改config-overrides.js，修改后的代码以下：

const { override, fixBabelImports, addWebpackAlias,useEslintRc } = require('customize-cra')
const path = require('path')
​
//重写配置
module.exports = override(
  // 配置路径别名
  addWebpackAlias({
    '@': path.resolve(__dirname, 'src')
 }),
  // antd按需加载
  fixBabelImports('import', {
    libraryName: 'antd',
    libraryDirectory: 'es',
    style: 'css'
 }),
  //启用eslintrc配置文件
  useEslintRc()
)

通过上述配置后，eslint 生效，npm start 会在控制台和浏览器中出现相关错误提示：

控制台报错：

浏览器报错：

2.4 忽略特定的文件或目录

在项目根目录建立一个 .eslintignore 文件告诉 ESLint 去忽略特定的文件和目录。.eslintignore 文件是一个纯文本文件，其中的每一行都是一个 glob 模式代表哪些路径应该忽略检测。例如：

build/*.js
public
dist
node_modules
config
config-overrides.js
src/serviceWorker.js
prettierrc
.DS_Store
.eslintrc.json
node_modules

2.5 eslint fix自动修复

eslint --fix 能够根据规范对代码的部分低级问题进行更正，如：缺乏/多余分号，缩进格式等。

可以修复的规范问题比较有限，须要较大变更才能修复的规范问题，eslint 没法自动修复。如：单行不能超过 80 个字符。

自动修复src文件夹下.js文件和.jsx文件部分规范问题，命令以下：

eslint --fix --ext .js --ext .jsx src/

三、eslint集成prettier

prettier 是一个「武断的」（官网用词： opinionated ）代码格式化工具。（只关心代码格式，统一代码风格）

根据规范，自动格式化代码，具备比 eslint auto-fix 更增强大的代码规范性修复能力。

官网：https://prettier.io/

3.1 安装prettier

根据 prettier官方建议，Prettier 版本升级后可能会有风格变化，故应当锁定 Prettier 的版本号。

npm install prettier --save-dev

3.2 安装eslint-plugin-prettier

ESLint插件，eslint-plugin-prettier 做为一个 ESLint的规则运行，并报告不一样的单个ESLint问题。

将 prettier 的能力集成到 eslint 中。按照 prettier 的规则检查代码规范性，并进行修复。

npm install eslint-plugin-prettier --save-dev

修改.eslintrc.json文件：

第一种方式：

//插件增长prettier
"plugins": ["react","prettier"],
//继承规则增长prettier
"extends": ["eslint:recommended","prettier"],
// 不符合 prettier 规则的代码，要进行错误提示（红线）
"rules":{
  "prettier/prettier":"error" 
},

第二种方式：

//至关于上面三个操做
{
    "extends": ["eslint:recommended","plugin:prettier/recommended"]
}

注：extends的含义

告诉 eslint，根据指定的规范，去检查指定类型的文件。如上例：

根据 eslint:recommended + prettier 规范，去检查 js 代码。

当某一类型的文件，被制定了不止1个规范，存在某些规范冲突时，后面的会覆盖掉前面的。

3.3 安装eslint-config-prettier解决冲突（若是存在冲突）

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

做用：解决冲突，让全部可能会与 prettier 规则存在冲突的 eslint rule 失效，并使用 prettier 的规则进行代码检查。至关于用 prettier 的规则，覆盖掉 eslint:recommended 的部分规则。

后面 prettier 格式化，也会根据这个规则来。所以，不会再有冲突。

3.4 prettier自动格式化

自动格式化src目录下的文件，命令以下：

prettier --write 'src/**/*.{js,css,jsx,html}'

3.5 自定义配置

根目录下新建.prettierrc文件，可根据须要进行一些自定义配置，示例以下：

{
   "printWidth": 100,
   "singleQuote": true,
   "trailingComma": "es5",
   "tabWidth": 4,
   "semi": true,
   "jsxBracketSameLine": false,
   "jsxSingleQuote": true,
   "useTabs": false
}

【注】这里的 .prettierrc，具备格式化规则的最高优先级。

3.6 忽略特定的文件或目录

在根目录下新建.prettierignore文件，直接添加文件名和目录名，与.eslintignore相似，示例以下：

build/*.js
public
dist
node_modules
config
config-overrides.js
src/serviceWorker.js
prettierrc
.DS_Store
.eslintrc.json
node_modules

prettier格式化的时候会忽略该配置文件中的文件或目录

四、编辑器自动格式化代码

4.1 使用编辑器快捷键，格式化代码

以 vscode 为例：shift + option + f，默认格式化规则选择 prettier，便可完成代码格式化。

4.2 保存代码自动格式化

一样以 vscode 为例，打开你的 settings.json，添加下面这句话：

"editor.formatOnSave": true

至此jsx，js、json、scss等文件，都可实现自动格式化。文件格式化规则，听从咱们在 .eslintrc.json 里的配置。也就是，使用咱们的 prettier 插件规则去格式化。

五、规范检查加强（husky + lint-staged）

在 git commit 以前，先强制执行prettier格式化（防止某些成员开发期间不开启编辑器格式化）、再检查代码规范，若是检查不经过、阻止提交。

5.1 安装 husky

npm install husky --save-dev

husky: git hook工具。这里主要用它防止不规范代码被commit、push、merge等等。

5.2 安装 lint-staged

npm install lint-staged --save-dev

Lint-staged提供了一个关键的功能，它能找到全部被git staged的文件，而不是工程下面全部的文件，而后经过管道交给Prettier作格式化。

5.3 配置husky和lint-staged

在package.json新增配置，以下：

    "husky": {
        "hooks": {
            "pre-commit": "lint-staged"
       }
   },
    "lint-staged": {
        "*.{js,jsx}": [
            "prettier --write",
            "eslint",
            "git add ."
       ]
   },

precommit由Husky处理，它会依照配置在把代码提交到仓库前运行lint-staged(也能够配置其余命令）。

Lint-staged再找到属于它本身的配置部分，即lint-staged键下面的配置。

上面的配置，git commit 以前，全部staged状态的，且扩展名是.js和.jsx的文件都会自动使用 prettier 格式化。格式化后，自动检查全部文件，是否所有符合 eslint 规范。

存在不符合规范的代码，git commit 将被终止。

修改代码，进行测试，结果以下：

与预期彻底一致，若是有不符合代码规范或语法错误的代码提交不了。输出错误信息，点击可定位到错误位置。

为什么必定要用lint-staged？

为何必定要用lint-staged，用Husky直接调用npm脚本不更简单么。配置以下：

 "scripts": {
        "start": "react-app-rewired start",
        "build": "react-app-rewired build",
        "test": "react-app-rewired test",
        "fix": "eslint --fix --ext .js --ext .jsx src/",
        "format": "prettier --write 'src/**/*.{js,css,jsx,html}'"
   },
  "husky": {
        "hooks": {
            "pre-commit": "npm run format && npm run fix"
       }
   },

若是是这样配置的话，就没有必要用lint-staged了。由于，这样的配置会把prettier，eslint应用到全部匹配.js,.jsx的文件上，而不是仅staged状态的文件。

5.4 husky扩展

5.4.一、单元测试检测

把单元测试加入到预提交检查中，保证只有经过了单元测试才正式提交代码到仓库。

配置以下：

 "husky": {
        "hooks": {
            "pre-commit": "lint-staged && npm test"
       }
   },

只是配上这个命令是不能跑的，仍是要集成Jest单元测试框架，编写单元测试代码。

5.4.二、commit messages规范与约束

git每次提交代码，都必须写commit message(提交说明)，用来讲明本次提交的目的，不然不容许提交。

commit message的写法规范有许多，目前使用最广的，比较合理和系统化的一种规范：Angular 规范。

工具commitizen/cz-cli会产生规范性的提示语句，帮助咱们造成规范的commit message。

工具commitlint用于检查咱们的commit message是否符合提交规范，若是不符合，则直接拒绝提交。

huskey配置以下：

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

5.5 husky不起做用怎么办

配置完成后 git commit 不起做用。

解决方案：确认 .git/hooks/* 下的文件，删除对应命令的文件，从新执行安装便可。

六、总结

规范仅仅经过人为的培训或者文档来约束，是不可靠的。

能经过工具约束的尽可能经过工具约束，而不要依靠默契和口头约定。

经过使用这些工具可以在必定程度上保证应用的质量问题，并能达到事半功倍的效果。

至此咱们开头的终极目标已实现~~！

七、引用

https://www.jianshu.com/p/56bee5bf1568

https://www.jianshu.com/p/f0d31f92bfab

http://www.javashuo.com/article/p-cytevpsq-cy.html

http://www.javashuo.com/article/p-rnpmpayx-ha.html

http://www.javashuo.com/article/p-dcxyqyxr-ws.html

还有引用其它文章一些内容，再也不一一列举了。。。。