共计 4501 个字符，预计需要花费 12 分钟才能阅读完成。
前端开发开发环境系列文章的 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.js | |
| webpack.* | |
| 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
| **/*.svg | |
| package.json | |
| /dist | |
| .dockerignore | |
| .DS_Store | |
| .eslintignore | |
| *.png | |
| *.toml | |
| docker | |
| .editorconfig | |
| Dockerfile* | |
| .gitignore | |
| .prettierignore | |
| LICENSE | |
| .eslintcache | |
| *.lock | |
| yarn-error.log | |
| .history | |
| CNAME | |
| /build | |
| /public |
在 eslint 中增加对应扩大
| module.exports = { | |
| ... | |
| "extends": [ | |
| ... | |
| "plugin:prettier/recommended" | |
| ], | |
| "plugins": [ | |
| ... | |
| "prettier" | |
| ], | |
| "rules": { | |
| ... | |
| "prettier/prettier": "error", | |
| } | |
| } |
.editorconfig 须要在 vscode 中配合 editorconfig 插件应用
| # http://editorconfig.org | |
| root = true | |
| [*] | |
| charset = utf-8 | |
| end_of_line = lf | |
| indent_size = 2 | |
| indent_style = space | |
| insert_final_newline = true | |
| max_line_length = 80 | |
| trim_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 lintgit 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 test | |
| npx --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.js | |
| module.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 配置优化
