前端开发开发环境系列文章的 github 在这,如果您在看的过程中发现了什么有余和谬误，感谢您能指出！

上一篇讲了如何创立一个简略的开发环境搭建，然而在一个我的项目中，只有这些是不够的。每个人的代码品质不同，格局不同。所以须要用到代码标准校验

eslint

它次要性能蕴含代码格局校验，代码品质校验

1. 首先，装置eslint

yarn add eslint -D(目前我用的是eslint v8.25.0, 高版本的eslint须要比拟新的vscode，不然eslint插件可能无奈工作)

2. 配置eslint规定和.eslintignore

后面咱们用到了react和typescript，所以也须要装置一下对应的插件和解析器
yarn add eslint-plugin-react @typescript-eslint/parser @typescript-eslint/eslint-plugin -D

.eslintrc.js

module.exports = {  "env": {    "browser": true,    "es2021": true  },  "extends": [    "eslint:recommended",    "plugin:react/recommended",    "plugin:@typescript-eslint/recommended"  ],  "parser": "@typescript-eslint/parser",  "parserOptions": {    "ecmaVersion": "latest",    "sourceType": "module"  },  "plugins": [    "react",    "@typescript-eslint",  ],  "rules": {    "arrow-body-style": "off",    "prefer-arrow-callback": "off",    "no-var": 2,    "no-console": 1,    "consistent-return": 1,    "default-case": 1,    "no-alert": 2,    "no-irregular-whitespace": 0,    "no-extra-boolean-cast": 0,    "no-unused-vars": "off",    "@typescript-eslint/indent": ["error", 2], // tab 缩进2空格  }}

.eslintignore

dist.eslintrc.jswebpack.*postcss.***/*.test.js

增加editorconfig和prettier来束缚代码的书写标准

对于它们两的区别就是，editorconfig它次要做一节比拟根底的格式化，如：Tab缩进几格、文件编码是否是utf-8等，和编程语言无关，你可能会在任何我的项目中看到它。而prettier是js特有的格式化工具，外面有很多配置项是js这门语言特有的标准。

它们的性能会有重叠，但大多数并不相同。所以前端我的项目往往两者都有。

总的来说就是在前端中，大部分editorconfig无能的，prettier也无能，它不能干的，prettier也无能。非要选一个的话，必定选prettier

而后将prettier标准扩大到eslint中，首先是须要装置prettier

eslint-plugin-prettier

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

而后配置.prettierrc.js

module.exports = {  tabWidth: 2,  semi: true,  singleQuote: true}

.prettierignore

**/*.svgpackage.json/dist.dockerignore.DS_Store.eslintignore*.png*.tomldocker.editorconfigDockerfile*.gitignore.prettierignoreLICENSE.eslintcache*.lockyarn-error.log.historyCNAME/build/public

在eslint中增加对应扩大

module.exports = {  ...  "extends": [    ...    "plugin:prettier/recommended"  ],  "plugins": [    ...    "prettier"  ],  "rules": {    ...    "prettier/prettier": "error",  }}

.editorconfig 须要在vscode中配合editorconfig插件应用

# http://editorconfig.orgroot = true[*]charset = utf-8end_of_line = lfindent_size = 2indent_style = spaceinsert_final_newline = truemax_line_length = 80trim_trailing_whitespace = true[*.md]max_line_length = 0

应用husky和lint-stage构建代码查看工作流

实现以上的配置后，咱们须要在package.json中增加两个script脚本,不便咱们在代码书写实现后运行命令来查看代码

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

然而这一步还是须要开发者手动实现。你不能保障每个人都有和你雷同的习惯。所以咱们须要有一个Lint环节(Code Linting)，他是保障代码标准一致性的重要环节。同时，他会缩小代码出错的概率。这也是变相的节约公司的工夫和本人的工夫。

而husky封装了githook，在代码提交前运行脚本对代码进行预检。

1. 装置husky

yarn add husky -D

2. 在package.json中增加一个script，并运行一次

{    "prepare": "husky install"}

yarn run prepare

3. 增加一个hook

npx husky add .husky/pre-commit "npm run lint"git add .husky/pre-commit

而后提交代码,他会在每次commit前运行npm run lint
git commit -m "Keep calm and commit"

然而在遗留代码库工作会遇到新的问题，开启Lint初期，你改变一个文件，可能其余文件中也有大量lint error须要修复。然而批改整个我的项目显然老本很高，且容易出错。所以为了稳固，必定是最好能lint批改的局部。其余的局部渐进批改。

基于这个想法lint-staged呈现了，stage就是git中的概念，指待提交区，在配合lint-stage后。你的每次commit都只会lint你的待提交区的批改过的代码。

用法如下：

首先装置
yarn add lint-staged -D

而后批改package.json配置，或者其余模式的配置文件

{  "lint-staged": {    "**/*.{js,jsx,ts,tsx}": "npm run lint",    "**/*.{js,jsx,tsx,ts,less,md,json}": [      "prettier --write"    ]  },}

而后在 .husky/pre-commit脚本中增加npx --no-install lint-staged命令，这样。每次commit前都会依据lint规定预检代码且通过prettier命令批改代码格局，并且这些操作都管制在了待提交区的代码中

.husky/pre-commit

#!/usr/bin/env sh. "$(dirname -- "$0")/_/husky.sh"npm testnpx --no-install lint-staged

应用commitlint + husky束缚commit信息格式

一个我的项目中，提交的信息也是十分的重要，如果没有标准束缚，提交的备注常常是形形色色的，十分不利于前期追踪和排查问题。

1. 装置相干库，后面曾经装置过了husky

yarn add @commitlint/config-conventional @commitlint/cli -D

commitlint是一个用来查看commit message格局是否符合要求的第三方工具，而husky是commit提交前的git hook，用来运行commit lint 标准

2. 配置commitlint.config.js标准

// commitlint.config.jsmodule.exports = {    extends: ["@commitlint/config-conventional"],    rules: {        "type-enum": [            2,            "always",            [                "feat", // 减少新性能                "fix", // 修复bug                "docs", // 只改变了文档相干的内容                "style", // 不影响代码含意的改变，例如去掉空格、扭转缩进、增删分号                "refactor", // 代码重构时应用                "test", // 增加测试或者批改现有测试                "build", // 结构工具的或者内部依赖的改变，例如webpack，npm                "chore", // 不批改src或者test的其余批改，例如构建过程或辅助工具的变更                "revert", // 执行git revert打印的message                "pref", // 晋升性能的改变                "merge" // 代码合并            ]        ],        "type-case": [0],        "type-empty": [0],        "scope-empty": [0],        "scope-case": [0],        "subject-full-stop": [0, "never"],        "subject-case": [0, "never"],        "header-max-length": [0, "always", 72]    }};

3. 增加shell脚本

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

执行完后，.husky目录如下

-- commit-msg- pre-commit

而后就能够批改代码，
而后git add . && git commit -m 'foo: change' 来测试了，失常会报错如下信息

type must be one of [feat, fix, docs, style, refactor, test, build, chore, revert, pref, merge] [type-enum]

总结

  • 应用eslint、editorconfig和prettier对代码的格局和品质进行校验
  • 应用husky和lint-stage构建代码查看工作流
  • 通过commitlint标准git commit

其余文章

  • 开发一个react+ ts+webpack的前端开发环境(一)------根底环境搭建
  • 开发一个react+ ts+webpack的前端开发环境(三)------webpack配置优化