从零配置 Eslint + Prettier + husky + lint-staged 构建前端代码工作流

写在前面

最近入职了新公司，领导让我修复项目中出现的bug，当我修复了bug提交代码的时候发现并没有提交上去而且还给我报了一堆的错误，于是我就发现了原来是在代码commit的时候用eslint去检查了代码，仔细看了看package.json发现gitHooks 在代码pre-commit(代码提交前的钩子)时期执行了lint-staged于是就去百度了husky可以在commit 或者 push 的时候去检验代码是否规范阻挡一些不合法的提交避免了不规范的代码提交到仓库里而lint-staged只针对git工作区的代码做linters这样就避免了检查整个仓库的代码。为了详细了解其中的配置我也是查了好多资料看了很多文档，但是总感觉别的文章讲的不是很全面，特别是eslint配置那块对像我这样的新手小白来说比较难以理解，所以就有了这篇从零配置前端项目工作流的文章。

链接

参考文章

准备工作

初始化项目

yarn init一路回车后创建好了package.json文件，接着git init初始化git仓库,后面我们要做代码提交的校验所以这里提前安装好方便后面的开发。

配置 .editorconfig

EditorConfig用于在基本代码库中维持一致的编码风格和设置，例如缩进样式、选项卡宽度、行尾字符以及编码等。这里可以根据具体项目用什么框架开发具体设置。

在vscode中搜索安装EditorConfig插件,根目录下新建 .edittorconfig文件写入一些配置代码。

// .editorconfig

root = true

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

[*.md]
trim_trailing_whitespace = false

配置 Eslint

关于 eslint

ESLint属于一种QA工具，是一个ECMAScript/JavaScript语法规则和代码风格的检查工具，可以用来保证写出语法正确、风格统一的代码。对eslint还不了解的同学这里提供了几个学习的网站。

深入浅出eslint——关于我学习eslint的心得

Eslint中文官网

在项目中安装 eslint

yarn add -D eslint

在项目中安装了eslint还不够我们想要的是在编辑器中也能够提示eslint的规则

在 vscode 中安装 eslint 插件

vscode 直接搜索eslint，安装插件后需要在settings.json中开启。

// settings.json 中的部分配置

{
    "editor.formatOnSave": false, // 每次保存自动格式化
    "editor.defaultFormatter": "esbenp.prettier-vscode",  
    "window.zoomLevel": 0, // 原始缩放比例
    "editor.codeActionsOnSave": { // 在保存时用eslint规则进行修复
    "source.fixAll.eslint": false
    },
    "eslint.enable": true,  //是否开启vscode的eslint
    "eslint.options": {    //指定vscode的eslint所处理的文件的后缀
      "extensions": [
          ".js",
          ".vue",
          ".ts",
          ".tsx"
      ]
    }
}

配置eslint规则

在根目录下新建.eslintrc.js文件并配置一条规则。

module.exports = {
    "env": {
        "browser": true,
        "es6": true
    },
    "rules": {
      "semi": ["error", "never"], // 禁止使用分号
    }
};

需要注意的是vscode下需要装eslint插件才能有相应的语法提示。

这时候我们写点示例代码到仓库中。

// src/a.js

const a = 'hello'; //这里我有意了一个分号让代码不符合eslint的规则

接下来vscode给我们把不符合eslint规范的错误抛出来了,值得一提的是eslint不仅明确了哪一行而且连官网的链接也给出了点击直接可以打开这条报错的规则。

让Eslint识别Typescript

我们已经能够让eslint识别出js代码了,但是这还远远不够要知道很多库已经在用ts,flow重构了，最近刚更新的vue3.0就是用ts写的。但是有没有必要在项目上使用ts还是依实际情况而定这里我们让eslint去识别Typescript的代码。

首先安装依赖:

yarn add typescript

yarn add -D @typescript-eslint/parser @typescript-eslint/eslint-plugin

@typescript-eslint/parser 是一个eslint的解析器,该解析器利用TypeScript ESTree允许ESLint整理TypeScript源代码。
@typescript-eslint/eslint-plugin 是eslint识别TypeScript规则的插件我们把他放入 extends 这个数组里。

// eslintrc.js
module.exports = {
    "parser":  '@typescript-eslint/parser', 
    "extends": ['plugin:@typescript-eslint/recommended'],
    "plugins": ['@typescript-eslint'],
    "env": {
        "browser": true,
        "es6": true
    },
    "rules": {
      "semi": ["error", "never"], // 禁止使用分号
    }
};

现在eslint可以识别Typescript的代码了我们尝试写点不规范的代码。

// src/b.ts

const b = 'hello';

Eslint --fix

eslint不仅可以帮我们提示代码的错误还可以自动帮我们修复，在package.json中写入eslint --ext .tsx,.ts,.js --fix ./src

"scripts": {
    "lint": "eslint --ext .tsx,.ts,.js --fix ./src"
}

运行 yarn lint 发现eslint自动帮我们去掉了代码块结尾的分号，其实eslint只能fix掉部分规范具体看文档的规则前面是否带了一个小扳手，如果带的话证明可以修复。

Prettier 一个美化代码风格神器

我们已经可以使用eslint去规范代码，接下来我们再使用prettier这个工具将代码格式化为统一的风格。

配置Prettier

根目录下新建配置文件.prettierrc.js。

module.exports =  {
  "printWidth": 120,
  "semi": false,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": false,
  "jsxBracketSameLine": true,
  "arrowParens": "avoid",
  "insertPragma": true,
  "tabWidth": 4,
  "useTabs": false  
};

安装 `Prettier` 依赖

yarn add -D prettier eslint-config-prettier eslint-plugin-prettier

eslint-config-prettier 用来关闭eslint和 prettier冲突的规则，我们要将这个放置在extends的最后，这样它就有机会覆盖其他配置。
slint-plugin-prettier前面我们关闭了eslint的规则，现在我们开启prettier的规则。

// eslintrc.js

module.exports = {
  "parser":  '@typescript-eslint/parser', //定义ESLint的解析器
  "extends": ['plugin:@typescript-eslint/recommended','plugin:prettier/recommended','prettier/@typescript-eslint'], //定义文件继承的子规范
  "plugins": ['@typescript-eslint','prettier'], //定义了该eslint文件所依赖的插件
    "env": {
        "browser": true,
        "es6": true
    },
    "rules": {
      "prettier/prettier": 1, //  eslint-plugin-prettier 使用prettier作为eslint规则
      "semi": ["error", "never"] // 禁止使用分号
    }
};

最后新增一条prettier --write命令这是prettier cli格式化的语法。

// package.json

"scripts": {
    "lint": "eslint --ext .tsx,.ts,.js --fix ./src",
     "fix": "prettier --write  ./src"
}

使用Prettier

运行 yarn fix 编辑器就可以根据.prettierrc.js里面的规范去美化代码了。

目前我们可以通过 yarn fix 去美化代码风格但是实际上往往会在提交前忘记yarn fix,有没有什么办法能在git commit的时候去检验代码并且修复不规范的代码，如果无法修复就阻止本次提交呢？显然是有的。

husky + lint-staged 构建代码工作流

husky 是一个 Git Hook 工具,它可以在代码提交前允许我们做一些事情，从而防止一些不好的代码被提交上去。
lint-staged 是针对工作区修改的文件,这对我们只希望处理将要提交的文件将会非常有用。

安装 husky lint-staged 依赖

yarn add -D husky lint-staged

注意 windows 用户需要使用 npm 包管理器安装不然 git hooks会失效

配置 husky & lint-staged

我们需要在代码提交前对代码做一下格式化并且如果代码不符合规范就不让提交,简单的做法就是在husky的pre-commit钩子去运行 lint-staged,lintstaged 主要就干了三件事：

第一件就是调用eslint --fix 修复不合符eslint规范的代码。

第二件prettier --write美化代码格式。

最后如果都通过了就允许代码commit。

// package.json 完整代码

{
  "name": "lint4",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^2.29.0",
    "@typescript-eslint/parser": "^2.29.0",
    "eslint": "^6.8.0",
    "eslint-config-prettier": "^6.11.0",
    "eslint-plugin-prettier": "^3.1.3",
    "husky": "^4.2.5",
    "lint-staged": "^10.1.7",
    "prettier": "^2.0.5"
  },
  "dependencies": {
    "typescript": "^3.8.3"
  },
  "scripts": {
    "lint": "eslint --ext .tsx,.ts,.js --fix ./src",
    "fix": "prettier --write  ./src"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*{.ts,.js}":[
      "eslint --ext .tsx,.ts --fix ./src",
      "prettier --write",
      "git add"
    ]
  }
}

案例

写点伪代码.....

git add .
git commit -m 'test'

perfect！

总结

以上就是本次分享的全部内容，对于一个中大型的项目来说规范代码的质量尤为重要。

我们已经学会了如何从零去配置一个项目的工作流，真实的场景可能是需要在vue或者react以及其他的框架中去配置husky、lint-staged、Typescripe等

简单回顾下工作流比较重要的几点：

通过Eslint去约束Javascript/Typescript
Prettier 美化代码，统一代码风格
使用 husky + lint-staged 在commit前做检查，避免存在不规范或者存在bug的代码入仓库

最后，感谢您阅读这篇文章，有任何问题或反馈请给我留言。