项目代码规范-Eslint+ Prettier+ commitlint

多人开发的项目，难免会出现代码风格不一致，而出现一些问题。统一代码风格能避免一些错误，提升开发体验，提高开发效率。为统一代码风格，在项目中引入eslint等插件，期望达到以下以下几点：

1. 开发过程中，对不规范代码给予提示
2. 能够对代码进行自动格式化
3. 代码提交时，校验代码是否符合规范。

Eslint 代码规范校验

$ pnpm install eslint eslint-plugin-vue -D

再初始化eslint配置文件

$ pnpm create @eslint/config

可以选择了不安装，手动安装命令如下：

$ pnpm add eslint-plugin-vue@latest @typescript-eslint/eslint-plugin@latest @typescript-eslint/parser@latest -D

修改.eslintrc.js配置：

module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true,
  },
  extends: [
    "eslint:recommended",
    "plugin:vue/vue3-recommended",
    "plugin:@typescript-eslint/recommended",
  ],
  parser: "vue-eslint-parser",
  parserOptions: {
    ecmaVersion: "latest",
    sourceType: "module",
    parser: "@typescript-eslint/parser",
  },
  plugins: ["vue", "@typescript-eslint"],
  rules: {},
  globals: {
    defineProps: "readonly",
    defineEmits: "readonly",
    defineExpose: "readonly",
    withDefaults: "readonly",
    defineOptions: "readonly",
  },
};

添加脚本：

{
  ...
  "scripts": {
    ...
    "lint": "eslint --ext .js,.vue,.ts --fix --quiet ./"
  },
  ...
}

运行pnpm lint就能自动修复一些简单的格式问题，也会抛出无法修复的报错。希望在开发的时候，就能把eslint问题修复，vscode可以安装eslint插件，可以实时校验并提示。安装完成之后，就有相关的eslint提示：

Prettier 代码格式化

eslint有一定修复代码格式的作用，但是还不够，需要结合prettier才能达到代码风格完全统一。安装prettier、eslint-config-prettier（主要解决prettier和eslint冲突问题）和eslint-plugin-prettier（接管）

$ pnpm add prettier eslint-config-prettier eslint-plugin-prettier -D

修改eslint配置，把prettier配置在extends最后

module.exports = {
  ...
  extends: [
    "eslint:recommended",
    "plugin:vue/vue3-recommended",
    "plugin:@typescript-eslint/recommended",
+    "prettier",
+    "plugin:prettier/recommended",
  ],
  ...
  rules: {
+    "prettier/prettier": "error",
    "vue/multi-word-component-names": "off",
  },
  ...
};

pnpm prettier --write . 验证一下是否生效：vscode安装prettier插件，让编辑器支持一键格式化安装完成之后，在代码窗口【右键】-【格式化文档】/【使用...格式化文档】-选择prettier，也可以用对应的快捷键还可以开启保存自动格式化文档，【首选项】-【设置】-搜索save，勾选【Format On Save】

Git提交规范

为了避免项目开发者提交不符合规范的代码，在提交的时候，则需要对代码进行格式化和校验。此外，也可以对git commit的massage进行约束，统一风格，让提交的内容更直观。使用以下几个工具：husky：git hook工具，触发hooks钩子，来执行一些自定义脚本lint-staged：负责检测git add .中暂存的文件commitlint：约束提交信息格式

husky

快速安装

$ pnpm dlx husky-init && pnpm install

husky-init会做以下几件事：

1. 在package.json中新增prepare命令
2. 创建一个可以编辑的pre-commit钩子（默认配置是：在commit的时候，执行npm test）
3. 配置Git钩子的路径

项目中会新增一个.husky文件，相关的配置内容可以在里面看到。

lint-staged

安装

$ pnpm add lint-staged -D

配置修改.husky/pre-commit的命令

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

# npm test
pnpm lint-staged

新建.lintstagedrc，在提交packages文件夹下的js、ts、vue文件的时候，进行eslint校验、prettier格式化

{
    "*.{js,ts,vue}": [
        "prettier --write",
        "eslint --max-warnings 5 --ext .js,.vue,.ts packages"
    ]
}

commitlint

安装

$ pnpm add @commitlint/{cli,config-conventional} -D

生成配置文件

$ echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

调整一下commitlint.config.js内容

module.exports = {
  extends: ["@commitlint/config-conventional"],
  rules: {
    "type-enum": [
      2,
      "always",
      [
        "ci",
        "docs",
        "feat",
        "fix",
        "perf",
        "refactor",
        "build",
        "chore",
        "revert",
        "style",
        "test",
      ],
    ],
    "subject-full-stop": [0, "never"],
    "subject-case": [0, "never"],
  },
};
//提交格式为 <type>(scope?): <subject>
/*
 * @Description: commit-msg提交信息格式规范
 *
 * commit-msg格式: <type>(scope?): <subject>
 *   - type: 用于表明我们这次提交的改动类型，是新增了功能？还是修改了测试代码？又或者是更新了文档？
 *     - build: 编译相关的修改，例如发布版本、对项目构建或者依赖的改动
 *     - chore: 其他修改, 比如改变构建流程、或者增加依赖库、工具等
 *     - ci: 持续集成修改
 *     - docs: 文档修改
 *     - feat: 新特性、新功能
 *     - fix: 修改bug
 *     - perf: 优化相关，比如提升性能、体验
 *     - refactor: 代码重构
 *     - revert: 回滚到上一个版本
 *     - style: 代码格式修改, 注意不是 css 修改
 *     - test: 测试用例修改
 *   - scope：一个可选的修改范围。用于标识此次提交主要涉及到代码中哪个模块。
 *   - Subject：一句话描述此次提交的主要内容，做到言简意赅
 */

配置husky

$ pnpm husky add .husky/commit-msg  'npx --no -- commitlint --edit ${1}'

此时提交代码的massage必须为<type>(scope?): <subject>格式，否则无法提交。检验是否生效git commit -m "test"，会报以下错误修改为git commit -m "feat: test"，能提交成功，说明配置没有问题。

至此，整个项目的代码规范配置就完成了。