代码规范：editorconfig配置、prettier格式化、ESLint检测、husky提交检测、commit规范

cocoCola91667
476 阅读8分钟

本文整理来自深入Vue3+TypeScript技术栈-coderwhy大神新课，只作为个人笔记记录使用，请大家多支持王红元老师。

一. 代码规范

1. 集成editorconfig配置

.editorconfig文件 有助于为不同 IDE 编辑器上处理同一项目的多个开发人员维护一致的编码风格。

# Editor configuration, see http://editorconfig.org

# 表示是最顶层的 EditorConfig 配置文件
root = true

[*] # 表示所有文件适用
charset = utf-8 # 设置文件字符集为 utf-8
indent_style = space # 缩进风格（tab | space）
indent_size = 2 # 缩进大小
end_of_line = lf # 控制换行类型(lf | cr | crlf), lf 适配 mac,linix ; cr 适配window;
trim_trailing_whitespace = true # 去除行首的任意空白字符
insert_final_newline = true # 始终在文件末尾插入一个新行

[*.md] # 表示仅 md 文件适用以下规则
max_line_length = off
trim_trailing_whitespace = false

如果想VSCode读取这个文件，需要安装一个插件：EditorConfig for VS Code。

2. 使用prettier工具

prettier [ˈprɪtiər] 
adv. | 颇; 相当; 十分; 非常; 极; 很; 
adj. | 漂亮的; 标致的; 妩媚的; 动人

Prettier 是一款强大的代码格式化工具，支持 JavaScript、TypeScript、CSS、SCSS、Less、JSX、Angular、Vue、GraphQL、JSON、Markdown 等语言，基本上前端能用到的文件格式它都可以搞定，是当下最流行的代码格式化工具。

如果使用的是VSCode，使用Prettier - Code formatter插件，按command+s保存即可对代码进行格式化。

如果使用的不是VSCode，甚至你想敲一个命令，通过这个命令就能对代码进行格式化，这时候最好在项目中安装Prettier的包， 安装之后，即使不用VSCode也可以对我们的代码进行格式化的。啥意思呢？也就是Prettier包是针对我们的项目的，插件是针对于VSCode的。

  1. 安装prettier
npm install prettier -D
  1. 配置.prettierrc文件
{
  "useTabs": false,
  "tabWidth": 2,
  "printWidth": 80,
  "singleQuote": true,
  "trailingComma": "none",
  "semi": false
}

useTabs：使用tab缩进还是空格缩进，选择false，使用空格；
tabWidth：tab是空格的情况下，是几个空格，选择2个；
printWidth：一行代码的长度，推荐80，也有人喜欢100或者120；
singleQuote：使用单引号还是双引号，选择true，使用单引号；
trailingComma：在多行输入的时候尾部是否添加逗号，设置为 `none`；
semi：语句末尾是否要加分号，默认值true，选择false表示不加；

3. 创建.prettierignore忽略文件

/dist/*
.local
.output.js
/node_modules/**

**/*.svg
**/*.sh

/public/*

4. VSCode需要安装prettier的插件

  1. 测试prettier是否生效

在代码中command+s保存代码，测试是否生效。如果我们去每个文件，然后一个一个command+s会很麻烦，我们可以在package.json中配置一个scripts，如下，这样我们执行npm run prettier命令就可以将项目中所有的文件格式化了。

"prettier": "prettier --write ."

当我们使用prettier格式化后的代码可能和ESLint的规则有冲突，从而有警告，下面讲一下ESLint。

3. 使用ESLint检测

ESLint是为了检查我们的代码是否规范。

  1. 在前面创建项目的时候，我们就选择了ESLint，所以Vue会默认帮助我们配置需要的ESLint环境，然后自动生成.eslintrc.js文件。
  2. VSCode需要安装ESLint插件

ESLint插件可以快速对我们的代码进行检查，从而报警告。

  1. 解决eslint和prettier冲突的问题

上面的.eslintrc.js文件，核心规范如下：

extends: [
  "plugin:vue/vue3-essential",   // vue3的规范
  "eslint:recommended",   // eslint默认推荐的规范
  "@vue/typescript/recommended",  // 在vue里面使用typescript的规范
  "@vue/prettier",  // 默认vue里面prettier的规范
  "@vue/prettier/@typescript-eslint",   // 默认vue里面prettier的typescript的规范
],

也就是说我们的代码需要符合上面那些规范，但是上面那些规范和.prettierrc里面的东西是冲突的，也就是说我们格式化之后代码会有警告，那么我们怎么让它兼容起来呢？

我们需要安装两个插件（vue在创建项目时，如果选择prettier，那么这两个插件会自动安装，就不用我们手动安装了）。

npm i eslint-plugin-prettier eslint-config-prettier -D
  • eslint-config-prettier：关闭eslint中与prettier相互冲突的规则。
  • eslint-plugin-prettier：赋予eslint用prettier格式化代码的能力。

这两个插件就是用来做eslint和prettier兼容的，然后修改.eslintrc文件，在extends中添加如下一行代码，表示用刚才的插件，然后重启项目，就不会警告了。

extends: [
  ......
  'plugin:prettier/recommended'
],

上面extends的规则都是继承，但是规则有相同的情况下，后面的会把前面的覆盖掉。

4. husky提交检测

husky 美[ˈhʌski]
adj. | 深沉沙哑的; 魁梧的; 高大威猛的;
n. | 爱斯基摩狗(高大强壮，毛厚，用来拉雪橇);

虽然我们已经要求项目使用eslint了，但是不能保证组员提交代码之前都将eslint中的问题解决掉了，也就是我们希望保证代码仓库中的代码都是符合eslint规范的，那么我们需要在组员执行 git commit 命令的时候对其进行校验，如果不符合eslint规范，那么自动通过规范进行修复。

那么如何做到这一点呢？可以通过husky工具，husky是一个git hook工具，可以帮助我们触发git提交的各个阶段：pre-commit、commit-msg、pre-push。

如何使用husky呢？这里我们可以使用自动配置命令：

npx husky-init && npm install

这个命令其实就是帮我们完成了3个操作：

  1. 安装husky相关的依赖
npm install husky -D

  1. 在项目目录下创建.husky文件夹
npx husky install

文件夹下面有个pre-commit文件，如果我们想在commit之前做一些事，可以在这个文件里面写操作。

  1. 在package.json中添加一个脚本

接下来，我们需要去完成一个操作：在进行commit时，执行lint脚本

这个时候我们执行git commit的时候会自动对代码进行lint校验。

补充：有时候windows电脑的cmd和powershell是不识别&&符号的，这时候我们可以加上引号''。

npx husky-init '&&' npm install

或者不使用自动命令，按照上面的步骤一步一步来就行了。

5. git commit规范

1. 代码提交风格

通常我们的git commit会按照统一的风格来提交，这样可以快速定位每次提交的内容，方便之后对版本进行控制。

但是如果每次手动来编写这些是比较麻烦的事情，我们可以使用一个工具：Commitizen，Commitizen 是一个帮助我们编写规范 commit message 的工具。

Commitizen 平民化的

  1. 安装Commitizen
npm install commitizen -D
  1. 安装cz-conventional-changelog，并且初始化cz-conventional-changelog
npx commitizen init cz-conventional-changelog --save-dev --save-exact

这个命令会帮助我们安装cz-conventional-changelog：

并且帮我们在package.json中进行配置：

这时候我们提交代码就要需要使用npx cz，执行之后会出现终端选择界面：

  1. 第一步是选择提交的type，本次更新的类型
Type作用
feat新增特性 (feature)
fix修复 Bug(bug fix)
docs修改文档 (documentation)
style代码格式修改(white-space, formatting, missing semi colons, etc)
refactor代码重构(refactor)
perf改善性能(A code change that improves performance)
test测试(when adding missing tests)
build变更项目构建或外部依赖（例如 scopes: webpack、gulp、npm 等）
ci更改持续集成软件的配置文件和 package 中的 scripts 命令，例如 scopes: Travis, Circle 等
chore变更构建流程或辅助工具(比如更改测试环境)
revert代码回退
  1. 第二步选择本次修改的范围（作用域）

  1. 第三步选择提交的信息

  1. 第四步提交详细的描述信息

  1. 第五步是否是一次重大的更改

  1. 第六步是否影响某个open issue

如果有组员不喜欢npx cz命令，我们可以在scripts中构建一个命令来执行cz，如下，我们执行npm run commit即可进行提交操作。

2. 代码提交验证

如果我们按照cz来规范了提交风格，但是依然有同事通过 git commit 按照不规范的格式提交应该怎么办呢？我们可以通过commitlint来限制提交。

  1. 安装 @commitlint/config-conventional 和 @commitlint/cli
npm i @commitlint/config-conventional @commitlint/cli -D
  1. 在根目录创建commitlint.config.js文件，配置commitlint，代码如下：
module.exports = {
  extends: ['@commitlint/config-conventional']
}

commitlint 推荐我们使用 config-conventional 配置去写 commit，它的格式和上面的commitizen是差不多的，如下：

git commit -m 'fix(account): 修复xxx的bug'
git commit -m 'refactor: 重构整个项目'

上面我们讲的pre-commit文件是commit之前的拦截文件，我们还需要拦截提交信息的文件，如下：

  1. 使用husky生成commit-msg文件，用来验证提交信息：
npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"

commit-msg文件内容如下：

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

# 检查我们的提交信息是否符合规范,不符合提交会失败
npx --no-install commitlint --edit

这时候我们再使用git commit提交代码的时候，如果不符合commitlint.config.js规范，就会报错。

avatar
文章
阅读
粉丝