配置 vite + typescript + EditorConfig + Prettier + ESLint + git Husky + Commitizen

1. .editorconfig 配置

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

• 配置 .editorconfig 文件后，通常还需要安装对应的编辑器插件来确保其生效。

• VSCode需要安装一个插件：EditorConfig for VS Code

• 在项目根目录下创建 .editorconfig 文件

  # http://editorconfig.org
  
  root = true
  
  [*] # 表示所有文件适用
  charset = utf-8 # 设置文件字符集为 utf-8
  indent_style = space # 缩进风格（tab | space）
  indent_size = 2 # 缩进大小
  end_of_line = lf # 控制换行类型(lf | cr | crlf)
  trim_trailing_whitespace = true # 去除行尾的任意空白字符
  insert_final_newline = true # 始终在文件末尾插入一个新行
  
  [*.md] # 表示仅 md 文件适用以下规则
  max_line_length = off
  trim_trailing_whitespace = false
  

2. .prettierrc 配置

• Prettier 是一个“有态度”的代码格式化工具，可以格式化代码，但不具备代码检查功能，它可以通过解析代码并使用自己的规则重新打印它，并考虑最大行长来强制一致的样式，并在必要时包装代码，如今，它已成为解决所有代码格式问题的优选方案，支持多种语言，可以将 ESLint 和 Prettier 结合使用，提高代码质量。

1. 安装 prettier

   npm install prettier -D
   

2. vscode 安装 Prettier - Code Formatter 插件

3. 在项目根目录下，新建并配置 .prettierrc 文件

   • useTabs：使用tab缩进还是空格缩进，选择false；
   • tabWidth：tab是空格的情况下，是几个空格，选择2个；
   • printWidth：当行字符的长度，推荐80，也有人喜欢100或者120；
   • singleQuote：使用单引号还是双引号，选择true，使用单引号；
   • trailingComma：是否使用尾随逗号（末尾的逗号），可以是 “none”、“es5”、“all” 三个选项；
   • semi：语句末尾是否要加分号，默认值true，选择false表示不加

   {
     "useTabs": false,
     "tabWidth": 2,
     "printWidth": 80,
     "singleQuote": true,
     "trailingComma": "es5", // 即在多行对象或数组中添加尾随逗号。
     "semi": false
   }
   

4. 新建并配置 .prettierignore 文件，用于忽略不需要格式化的文件

   /dist/*
   .local
   .output.js
   /node_modules/**
   
   **/*.svg
   **/*.sh
   
   /public/*
   

5. VSCode 中配置：

   • 保存时自动格式化：文件》首选项》设置》 搜索 format on save 》勾选上
   • 设置格式化程序：文件》首选项》设置》搜索 editor default formatter 》 选择 prettier - Code formatter

6. 测试prettier是否生效

   • 方式一：在代码中保存代码
   • 方式二：根据配置文件一次性修改所有文件，在package.json中配置一个scripts，该命令将会对所有文件进行格式化（排除.prettierignore 文件中配置的）
     • 当代码提交之后可以运行npm run prettier ，以确保 prettier 配置成功

   "scripts": {
       // ...其他
       "prettier": "prettier --write ."
   }
   

3. ESLint 配置

• ESLint 是一个可配置的 JavaScript linter。它可以帮助你发现并修复 JavaScript 代码中的问题。问题可以是任何事情，从潜在的运行时错误到不遵循最佳实践，再到样式问题。
• ESLint 是完全插件化的。每条规则都是一个插件，你可以在运行时添加更多。你还可以添加社区插件、配置和解析器来扩展 ESLint 的功能。

1. 在项目创建时，已经生成了 ESLint 的配置文件 eslint.config.js （ESlint 9 开始 配置文件和配置方法已经改变）

2. VSCode需要安装ESLint插件

3. 为了确保 ESLint 和 Prettier 不冲突，安装插件

   npm install eslint-config-prettier eslint-plugin-prettier --save-dev
   

4. 修改 eslint.config.js

   import js from '@eslint/js'; // 提供了 JavaScript 的 ESLint 配置。
   import globals from 'globals'; // 提供预定义的全局变量集合，这里使用的是浏览器环境的全局变量。
   import reactHooks from 'eslint-plugin-react-hooks'; // 提供 React Hooks 的 ESLint 规则。
   import reactRefresh from 'eslint-plugin-react-refresh'; // 提供 React Fast Refresh 的 ESLint 规则。
   import tseslint from 'typescript-eslint'; // 提供 TypeScript 的 ESLint 规则。
   import eslintPluginPrettierRecommended from 'eslint-plugin-prettier/recommended';
   // import prettier from 'eslint-plugin-prettier'
   
   export default tseslint.config(
     { ignores: ['dist'] }, // 忽略文件夹
     {
       extends: [
         js.configs.recommended,
         ...tseslint.configs.recommended,
         // 'plugin:prettier/recommended', // 禁用与 Prettier 冲突的规则
       ],
       files: ['**/*.{ts,tsx}'], // 文件匹配规则
       languageOptions: {
         ecmaVersion: 2020,
         globals: globals.browser,
       },
       plugins: {
         'react-hooks': reactHooks,
         'react-refresh': reactRefresh,
       },
       rules: {
         ...reactHooks.configs.recommended.rules,
         'react-refresh/only-export-components': [
           'warn',
           { allowConstantExport: true },
         ],
       },
     },
     eslintPluginPrettierRecommended
   );
   

5. 可以使用如下命令校验 eslint 是否生效(在app.tsx 文件中添加 debugger, 或者只定义未使用的变量，不用下边的命令也会报错)

   # 可以用.表示所有文件
   npx eslint src/App.tsx
   

6. 在 package.json 中配置一个 scripts，该命令将会对所有文件进行代码检查（当然不会校验 .prettierignore 文件中配置的文件）

   // 该命令已经存在于 package.json 中
   "scripts": {
       "lint": "eslint .",
   }
   

   如果希望自动修改可以使用 --fix ：尝试自动修复一些可以自动修正的问题；–quiet：只报告错误，不报告警告信息，使得输出更加简洁。

   "scripts": {
       // ...其他
       "lint": "eslint --fix --quiet ./",
   }
   

7. 然后执行 npm run lint 命令（关于校验的哪些文件，已经在 eslint.config.js 中的 files 选项配置）

8. vite 中引入 ESLint 插件，以便在开发阶段发现问题

   • vite-plugin-eslint 会报错，需要安装 vite-plugin-eslint2

   npm i vite-plugin-eslint2 -D
   

9. 在 vite.config.ts 文件中引入 ESLint 插件

   // ...其他引入
   import eslint from 'vite-plugin-eslint2';
   
   export default defineConfig({
     plugins: [react(), eslint()],
     // ...其他配置
   });
   

10. 弄好之后，重启 VSCode，就可以看到 ESLint 的报错提示了

4. git Husky 配置

• 虽然我们已经要求项目使用 ESLint了，但是不能保证组员提交代码之前都将 ESLint 中的问题解决掉了，也就是我们希望保证代码仓库中的代码都是符合 ESLint 规范的；那么我们需要在组员执行 git commit 命令的时候对其进行校验，如果不符合 ESLint 规范，那么自动通过规范进行修复；
• 可以通过Husky工具做到这点：husky是一个git hook工具，可以帮助我们触发git提交的各个阶段：pre-commit、commit-msg、pre-push

1. 安装 husky

   npm install husky -D
   

2. 初始化 husky，将会在根目录下创建 .husky 目录

   npx husky init
   

3. 将会自动在 package.json 文件中添加运行脚本

   "scripts": {
       // ...其他
       "prepare": "husky"
   }
   

4. 修改 .husky/pre-commit 文件，添加如下代码， 每次提交之前都会对所有文件进行校验（因为 package.json 文件中 lint 命令设置的文件路径是 ./）

   npm run lint
   

5. 将会在 git 提交之前执行文件中的命令npm run lint（就是执行 lint 命令，校验所有文件是否 ESLint 的配置符合规范）

5. 使用 lint-staged 只校验改动的代码

• 通常 husky 与 lint-staged 搭配使用，lint-staged 用于仅对添加到了暂存区的文件校验，避免了不必要的每次提交时全局校验。

1. 安装 lint-staged

   npm install lint-staged -D
   

2. 在 package.json 文件中添加运行脚本和相关配置。这个配置可以在提交信息的时候记进行 eslint 检测和格式化代码。
   • 注意 文件的后缀名，如果是 react 项目则是 "src/*.{ts,js,tsx}" 如果是 vue 项目 则是 "src/*.{ts,js,vue}",其他项目同理

   "scripts": {
       // ...其他
       "lint-staged": "lint-staged"
   },
   "lint-staged": {
      // "**/*.{ts,js,tsx}" 针对所有目录
      // 只针对 src 目录
      "src/*.{ts,js,tsx}": [
         // "npm run prettier", // 格式化所有文件
         // "npm run lint", // 校验代码，会检查所有文件
        "eslint --fix",  // 校验git缓存区中的文件，并自动修复一些简单的错误
        // "prettier --write", // 格式化git缓存区中的文件（格式化之后的代码如果有新的变动，需要重新执行一次添加操作）
      ]
   },
   

3. 将代码添加到暂存区 （git add .），然后执行 npm run lint-staged
4. 修改 .husky/pre-commit 文件，在提交时只校验暂存区中的文件

   npm run lint-staged
   

6. 使用 Commitizen 规范 commit 信息

• 通常我们的git commit会按照统一的风格来提交，这样可以快速定位每次提交的内容，方便之后对版本进行控制。
• 但是如果每次手动来编写这些是比较麻烦的事情，我们可以使用一个工具：Commitizen

1. 安装Commitizen

   npm install commitizen -D
   

2. 安装cz-conventional-changelog，并且初始化cz-conventional-changelog：

   npx commitizen init cz-conventional-changelog --save-dev --save-exact
   

3. 上边的命令将会在 package.json 文件中添加如下信息

   "config": {
       "commitizen": {
           "path": "./node_modules/cz-conventional-changelog"
       }
   }
   

4. 使用 git add . 将文件添加到暂存区
5. 使用 npx cz 将显示一个交互信息，根据自己的需求选择对应的选项，就会自动生成一个符合规范且符合 ESLint 规范的 commit 信息
   • Select the type of change that you’re committing:
     • feat: 新增功能， fix：修改bug， docs：修改文档，style：代码格式修改，refactor：代码重构，perf：改善性能，test：测试，build：变更项目构建或外部依赖
   • What is the scope of this change (e.g. component or file name): 可以输入自己更改的文件名也可以跳过
   • Write a short, imperative tense description of the change (max 86 chars): 本次提交的信息（简短描述）
   • Provide a longer description of the change: (press enter to skip) 本次提交的信息（详细描述）
   • Are there any breaking changes? (y/N) 有非常大的更改吗
   • Describe the breaking changes: 描述这次大的更改
   • Does this change affect any open issues? 这一变化是否会影响任何悬而未决的问题
   • Add issue references: 添加bug号
6. 在 package.json 文件中添加运行脚本，执行 npm run cz 和 npx cz 效果一样

   "scripts": {
       // ...其他
       "cz": "cz"
   }
   

7. 配置到这里，以后需要提交代码，就要先将代码提交到暂存区git add . 然后运行 npm run cz 或 npx cz 命令，然后根据提示进行操作

7.使用 commitlint 限制提交信息

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

1. 安装 @commitlint/config-conventional 和 @commitlint/cli

   npm i @commitlint/config-conventional @commitlint/cli -D
   

2. 在根目录创建 commitlint.config.js 文件，配置commitlint

   export default {
   	extends: ['@commitlint/config-conventional'],
   };
   

3. 在 .husky 文件夹下创建 commit-msg 文件，文件内容如下，该文件将会校验本此提交是不是使用 npx cz 方式

   npx --no -- commitlint --edit "$1"