写代码不规范，同事两行泪 😭（工程化如何让团队协作更高效）

前言

在实际的前端项目中，你是否也遇到过这样让人头疼的情况：

• 新同事刚加入，看到一堆奇怪的命名、冗长的函数，完全不知道如何下手，心里默默吐槽：这真的是我需要维护的吗？
• 每次修改需求或者修复 bug，都得提心吊胆，因为你担心修改了一个地方，可能会影响到其他地方的功能，最终导致出现更多 bug，团队陷入"多修多乱"的恶性循环。
• 每次提交代码前都得花好久时间检查格式、规范，甚至还得手动修正一些小细节，不仅浪费了时间，而且还给团队的工作进度拖了后腿。

一系列问题都源自代码不规范以及缺乏系统的工程化管理，导致团队协作效率低下，开发周期不断延长，你开始发现，团队成员之间的沟通和协作逐渐变成了"甩锅大战"，每次交付后都有人责怪别人做得不好，项目进度也因为这些问题而不断延迟，但是，不用担心！这些问题都能通过工程化手段 解决，看完这篇文章之后，你会掌握一套实用、落地、可扩展的前端工程化流程，不仅能让你的代码变得健壮、清晰、可维护，更能大幅提升团队协作效率。从现在开始，一起告别"屎山代码"，让项目稳、团队顺、交付快！💪

工程化步骤

一，代码规范化检查

作为开发者，最基础也是最重要的一步，就是确保代码风格统一 并避免低级错误。 举个最常见的例子：我们团队习惯使用 2 个空格缩进，而有些同事的编辑器默认是 4 个空格。如果大家没有统一规范，每次提交或拉取代码时，编辑器自动格式化缩进，就会导致整个文件看起来"被修改"了------实际上只是缩进不同。

结果是什么呢？git显示整份文件被改动，真正的功能变更却淹没在格式变更中，代码审查困难，协作效率低下。 所以，做好前端工程化的第一步，就是引入代码规范校验工具，从源头上保证风格一致性，避免这种"谁改了哪里都不知道"的情况。

1. prettier（代码格式化）

prettier 是什么？prettier 是一款代码格式化工具，顾名思义，它可以帮助我们把代码"变漂亮"。它支持包括 JavaScript、TypeScript、CSS、HTML、JSON、Markdown 在内的多种文件类型，可以统一代码风格，让团队协作更高效，真正实现团队风格统一。

1.1 安装prettier

npm install prettier -D

1.2 创建 .prettierrc 配置文件

这是 prettier 的配置文件，我们可以根据团队规范来定义格式化规则，比如：

{
  "useTabs": false,
  "tabWidth": 2,
  "printWidth": 80,
  "singleQuote": true,
  "trailingComma": "none",
  "semi": false
}

常见配置解释：

• useTabs: 是否使用 Tab 缩进，false 表示用空格；
• tabWidth: 每个缩进的空格数，建议设为 2；
• printWidth: 每行最大字符数，推荐 80（也有人设为 100 或 120）；
• singleQuote: 是否使用单引号，true 为使用；
• trailingComma: 是否在多行对象、数组末尾加逗号，设置为 none；
• semi: 语句末尾是否加分号，false 表示不加；

1.3 创建.prettierignore忽略文件

用于忽略不需要格式化的文件或目录，例如：

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

1.4 测试prettier是否生效

我们可以直接在终端输入

npx prettier --write .

或者在 package.json中添加脚本：

"scripts": {
  "prettier": "prettier --write ."
},

执行命令：

npm run prettier

控制台有打印说明就是成功了，但是这个是使用命令美化代码，如果我们每次保存得时候都执行一下这个命令那么就比较消耗时间，效率慢，但是如果我们希望每次编辑器保存代码得时候就帮我们美化呢，那么此时我们就需要装一个prettier插件

1.5 VSCode 安装 prettier 插件

1.6 VSCode 实现保存自动格式化

• settings =>format on save => 勾选上
• settings => editor default format => 选择 prettier=>格式化选择prettier；

这样，每次保存文件时，prettier 就会自动帮我们美化代码，无需手动操作，提高效率又不容易出错。

2. eslint（代码质量检测）

什么是 eslint 呢？从名字拆开来看，其实就是 ES（ECMAScript） + Lint（代码检查） 。它最初是为了 检查 JavaScript 代码中的语法错误和风格问题 而诞生的。但发展到今天，eslint 已经不仅仅是一个 JavaScript 校验工具了，而是一个功能强大、可扩展的代码质量检查框架，支持 JavaScript、TypeScript、Vue、React、JSON、Markdown、YAML 等多种格式。

eslint 主要用于检查语法错误、潜在的 bug、不规范的写法，以及团队统一的编码风格等问题。而 prettier 专注于代码格式化。两者配合使用时，prettier 负责格式化代码，eslint 负责代码规范和逻辑问题检查，从而保障代码的整洁性和健壮性。

2.1 安装 eslint

首先，我们需要安装 eslint：

npm install eslint --save-dev

2.2 初始化配置

接下来，我们通过命令行工具初始化 eslint 配置：

npx eslint --init

按提示选择适合你项目的配置（如语法检查、模块类型、是否使用 TypeScript、运行环境等）。如果你在创建 Vue 项目时已经选择了 eslint，这里可以跳过这一步。

这里就用官方初始化的方法

在终端选择完这些选项

√ How would you like to use ESLint? · problems    
√ What type of modules does your project use? · commonjs
√ Which framework does your project use? · none
√ Does your project use TypeScript? · javascript
√ Where does your code run? · node
The config that you've selected requires the following dependencies:

eslint, globals, @eslint/js
√ Would you like to install them now? · No / Yes
√ Which package manager do you want to use? · npm
☕️Installing...

最终会生成一个 eslint.config.mjs 文件，如下：

//eslint.config.mjs
import { defineConfig } from 'eslint/config'
import globals from 'globals'
import js from '@eslint/js'

export default defineConfig([
  { files: ['**/*.{js,mjs,cjs}'] },
  { files: ['**/*.js'], languageOptions: { sourceType: 'commonjs' } },
  { files: ['**/*.{js,mjs,cjs}'], languageOptions: { globals: globals.node } },
  { files: ['**/*.{js,mjs,cjs}'], plugins: { js }, extends: ['js/recommended'] }
])

2.3 测试 eslint 是否生效

我们给eslint配置添加上分号检查还有const，如下

import { defineConfig } from 'eslint/config'
import globals from 'globals'
import js from '@eslint/js'

export default defineConfig([
  { files: ['**/*.{js,mjs,cjs}'] },
  { files: ['**/*.js'], languageOptions: { sourceType: 'commonjs' } },
  { files: ['**/*.{js,mjs,cjs}'], languageOptions: { globals: globals.node } },
  {
    files: ['**/*.{js,mjs,cjs}'],
    plugins: { js },
    extends: ['js/recommended'],
    rules: {
      semi: 'error', // 强制分号，违反时报错
      'prefer-const': 'error' // 强制用 const 声明未修改的变量
    }
  }
])

比如我们代码里面有一段代码是这样的

let a = 'xiaoming'
console.log(a)

我们可以在终端执行下面语句

npx eslint .    #检查所有文件

这个是时候他就会告诉你，a不会被修改，所以用const来声明未修改的变量，然后还有就是没有分号

  1:5   error  'a' is never reassigned. Use 'const' instead  prefer-const
  1:19  error  Missing semicolon                             semi
  2:15  error  Missing semicolon                             semi

如果你用检查并修复这个命令的

npx eslint . --fix #自动修复

它会根据 ESLint 的规则修复我们的代码，比如加上分号、将 let 改为 const。不过，这只是简单的语法修复，对于一些复杂的语法，ESLint 是无法自动修复的，需要自己来。

const a = 'xiaoming';
console.log(a);

2.4 eslint 与 prettier 冲突问题（eslint-plugin-prettier）

其实我们前面用 eslint 修复代码时是加了分号的；但 prettier 的规则是去掉分号，于是就出现了一个循环：

• 你写完代码后保存，prettier 自动格式化，把分号删了；
• 然后你用 eslint 一修复，分号又被加回来；
• 下一次你再保存，prettier 又把分号删掉；
• 如此往复，进入"你加我删"的死循环。

这个过程有个很大的问题：你可能根本没意识到有冲突，但 git却记录了一堆无意义的修改。比如今天你加了几个 console，保存之后 prettier 把分号去掉了；然后 eslint 又加回来；最后你提交的时候，看起来改了 20 行，其实只是反复在加减分号。

更糟糕的是，你可能没注意到这个问题就提交了，别人一拉代码，也触发了这个循环，整个项目的 git记录就充满了"脏改动"，团队协作效率会被拉低不少。

有没有办法让我们提前发现这种 eslint 和 prettier 的冲突？答案是有的，就是用 eslint-plugin-prettier 这个插件。

它的作用就是：把 prettier 的格式化结果也当作 eslint 的错误来报出来，这样一旦规则冲突（比如分号要不要加），你 eslint 一运行就能看到错误提示，而不是等到触发死循环才发现问题。

一旦我们能及时拦截并看到这些冲突，就可以有意识地去解决它们，避免无意义的改动污染版本历史。

安装

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

然后修改一下eslint的配置

import { defineConfig } from 'eslint/config'
import globals from 'globals'
import js from '@eslint/js'
import prettierPlugin from 'eslint-plugin-prettier'

export default defineConfig([
  { files: ['**/*.{js,mjs,cjs}'] },
  { files: ['**/*.js'], languageOptions: { sourceType: 'commonjs' } },
  { files: ['**/*.{js,mjs,cjs}'], languageOptions: { globals: globals.node } },
  {
    files: ['**/*.{js,mjs,cjs}'],
    plugins: { js, prettier: prettierPlugin }, //使用 eslint-plugin-prettier插件
    extends: ['js/recommended'],
    rules: {
      semi: 'error', // 强制分号，违反时报错
      'prefer-const': 'error', // 强制用 const 声明未修改的变量
      'prettier/prettier': 'error' //规范prettier规则报error
    }
  }
])

我们再执行一下

npx eslint . --fix #自动修复

就会提示告诉你

(node:23180) eslintCircularFixesWarning: Circular fixes detected while fixing F:\demo\practice-git-and-engineering\commitlint.config.js. It is likely that you have conflicting rules in your configuration.
4:2  error  Delete `;`               prettier/prettier

这个提示其实就是告诉你，在修复文件时遇到了"死循环"问题，也就是我们之前提到的那种情况。prettier 的规则会把分号去掉，而 eslint 又会报告分号缺失的错误，导致两者在修复时互相冲突。一旦 eslint 检测到 prettier 的格式化规则（比如分号），它就会将其当作错误报告给你，这样你就能及时发现冲突的根源。

发现问题后，我们就可以选择解决冲突：prettier 不需要分号，而 eslint 需要分号 ，那么解决办法就是干脆去掉 eslint 中 semi: 'error' 的规则，让 prettier 来管格式化，避免冲突。

修改后的配置文件

import { defineConfig } from 'eslint/config'
import globals from 'globals'
import js from '@eslint/js'
import prettierPlugin from 'eslint-plugin-prettier'
export default defineConfig([
  { files: ['**/*.{js,mjs,cjs}'] },
  { files: ['**/*.js'], languageOptions: { sourceType: 'commonjs' } },
  { files: ['**/*.{js,mjs,cjs}'], languageOptions: { globals: globals.node } },
  {
    files: ['**/*.{js,mjs,cjs}'],
    plugins: { js, prettier: prettierPlugin }, //使用 eslint-plugin-prettier插件
    extends: ['js/recommended'],
    rules: {
      // semi: 'error', // 强制分号，违反时报错
      'prefer-const': 'error', // 强制用 const 声明未修改的变量
      'prettier/prettier': 'error' //规范prettier规则报error
    }
  }
])

但是，如果规则比较多，逐个去掉会非常麻烦。那么有没有一种方式可以自动将 prettier 的规则与 eslint 兼容呢？答案是有的，那就是 eslint-config-prettier 。它是一个 eslint 插件，主要作用是将 prettier 的格式化规则作为 eslint 的规则来执行，这样你就可以通过 eslint 来统一检查和修复代码格式问题，确保代码质量和风格检查的流程更加一致高效。

2.5 彻底解决冲突（eslint-config-prettier）

eslint-config-prettier 的作用是禁用 eslint 中与 prettier 冲突的格式化规则，例如 eslint 的 semi、indent、quotes 等格式相关规则。它会移除这些规则，并让 prettier 的规则成为标准。具体来说，eslint-config-prettier 禁用了所有可能与 prettier 产生冲突的规则，让 prettier 完全负责代码风格的处理，而 eslint 则专注于代码质量检查（例如变量是否已定义、函数参数是否多余等）。

安装eslint-config-prettier

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

然后我们修改一下eslint的配置

import { defineConfig } from 'eslint/config'
import globals from 'globals'
import js from '@eslint/js'
import prettierPlugin from 'eslint-plugin-prettier'
//---新增---
import prettierConfig from 'eslint-config-prettier'

export default defineConfig([
  { files: ['**/*.{js,mjs,cjs}'] },
  { files: ['**/*.js'], languageOptions: { sourceType: 'commonjs' } },
  { files: ['**/*.{js,mjs,cjs}'], languageOptions: { globals: globals.node } },
  {
    files: ['**/*.{js,mjs,cjs}'],
    plugins: { js, prettier: prettierPlugin }, //使用 eslint-plugin-prettier插件
    extends: ['js/recommended'],
    rules: {
      semi: 'error', // 强制分号，违反时报错
      'prefer-const': 'error', // 强制用 const 声明未修改的变量
      'prettier/prettier': 'error' //规范prettier规则报error
    }
  },
  //---新增---
  prettierConfig //放在最后，后面的配置项拥有更高优先级，可以覆盖前面的规则
])

然后我们执行

npx eslint . --fix

最终，发现没有报错了。即便你在 eslint 配置中设置了 semi: 'error'，由于 eslint-config-prettier 最终会覆盖这个规则，最终的规则会以 prettier 为准，从而避免了冲突的发生。

二，提交前的代码校验

在开发过程中，我们通常会使用 prettier 和 eslint 来确保代码的格式和质量符合规范。但问题来了，有些同事可能会看到 eslint 报错，依然选择无视或强行提交。这种情况就会导致，其他同事拉取代码后，眼前一片红色的警告，格式混乱、代码难以阅读，那么我们有没有什么办法，阻止有问题的代码提交，答案是有的，那就是 git钩子。

1. git钩子

git钩子是什么呢，git钩子（gitHooks）是 git提供的一个功能，它能够在特定事件发生时自动触发脚本执行。例如：

• pre-commit：在提交代码前触发（适合运行代码检查、格式化）。
• commit-msg：在提交信息写完后触发（适合校验提交信息格式）。
• pre-push：在推送代码前触发（适合运行测试）。

这意味着，如果你配置了钩子，git就会在你提交、推送之前自动运行你设定的命令，确保提交的代码是符合规范的。

但是默认情况下，git钩子存储在项目的 .git/hooks 目录中，但它们是本地化的（不纳入版本控制），且需要手动配置，就是.git 目录是 git内部管理仓库的核心目录，git本身不会跟踪这个目录的内容 。也就是说，如果你在 .git/hooks 中添加了钩子脚本，这些脚本，不会提交到代码仓库，其他团队成员拉取代码时，不会自动获取你的钩子配置，仅对当前本地仓库生效 ，每个开发者需要在自己的电脑上单独配置，无法共享。为了让团队共享这些钩子配置，我们需要引入一个好用的工具 ------ husky。

2. husky

什么是husky？husky 可以帮我们在 git钩子配置纳入项目版本控制，团队共享同一套规则，自动化触发流程 ，在 git操作的关键节点自动执行脚本（如代码检查、提交校验，强制规范执行：防止开发者绕过代码检查或提交规范

安装 husky：

npm install husky --save-dev
npx husky init

安装完成后，项目根目录下会出现一个 .husky 文件夹。你会看到一个 pre-commit 的钩子文件，默认情况下，它会在每次提交前执行 npm test。来，我们做个简单的测试：

git add .
git commit -m "测试husky"

可以看到，npm test 会在提交前执行，表示 husky 配置成功。

3. husky+prettier+eslint组合使用

那么，如何在提交前让 prettier 和 eslint 自动检查和格式化我们的代码呢？只需要修改 pre-commit 钩子文件中的命令：

npx prettier --write . && npx eslint . --fix

这样，每次提交前，husky 会自动运行 eslint 和 prettier，确保你的代码格式和质量都符合规范。

我们来试试：

git add test.js
git commit -m "测试husky+prettier+eslint"

你会看到，prettier 会自动格式化你的代码，而 eslint 会帮你修复一些小问题，整个提交流程就变得非常规范和高效。

然而，这里有一个小问题：prettier 和 eslint 会对整个项目中的所有文件进行检查。即使你只修改了 test.js，它也会检查其他所有文件，这样会浪费很多时间，尤其是当项目比较大的时候。为了解决这个问题，我们可以引入 lint-staged ，这个工具会让我们只检查那些被暂存（git add）的文件，从而大大提升性能。

4. lint-staged

什么是 lint-staged？顾名思义，这个工具专门用于检查 git暂存区的文件，也就是说，它只会对你通过 git add 命令添加到暂存区的文件进行 lint 检查。

如果每次提交几个文件，却还要对所有文件进行 lint，显然是不必要的浪费时间。我们只需要对即将提交的代码进行 lint 检查，避免了对其他文件的冗余处理，从而节省了很多时间和计算机性能。

安装 lint-staged：

npm install lint-staged --save-dev

然后，在 package.json 中添加如下配置：

"lint-staged": {
  "*.{js,jsx,ts,tsx}": [
    "prettier --write",
    "eslint --fix"
  ]
}

这段配置表示，每次提交时，所有 .js、.jsx、.ts 和 .tsx 文件都会被 prettier 和 eslint 检查并修复。

然后手动运行 lint-staged 来检查暂存区的文件：

npx lint-staged

就可以对缓存区的进行代码检测了，但是我们这个是手动的，所以我们可以利用我们上面的husky 加lint-staged组合使用，岂不是更方便更香，所以继续改配置

我们找到husky 下面的pre-commit将其中的命令改为

npx lint-staged

这样，每次提交时，husky 会自动触发 lint-staged ，只对暂存区的文件进行 prettier 和 eslint 检查。

最后，试试这个流程：

git add test.js
git commit -m "测试husky-lint-staged"

你会发现，husky 和 lint-staged 执行成功，确保只有你改动的文件才会被检查，而且整个过程非常高效，快速了。

三，提交信息的规范化

1. commitizen

commitizen 是什么呢？简单来说，它是用来规范 git提交信息的工具。大家有没有遇到过这样的情景，在提交代码时，写下类似 git commit -m "更新了一点" 或 git commit -m "更新了一些" 这样的信息，或者同事提交信息的时候这样子提交，格式混乱且无法清楚表明修改了什么内容？这时候，commitizen 就能帮我们规范这些提交信息，让提交变得更加有规则和易于理解。

安装 commitizen

npm install commitizen -D

接下来，我们需要安装适配器 cz-conventional-changelog，并初始化它，cz-conventional-changelog 是 commitizen 的"规则引擎"，它封装了 Angular 的提交规范，成为一个通用的工具，帮助我们规范提交信息的格式。

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

执行完后，你会看到在 package.json 文件中自动添加了以下配置：

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

此时，我们在提交代码时，需要使用 npx cz 来替代 git commit。

提交步骤：

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	代码回退

2. 选择修改范围 (scope)：用来说明这次提交的影响范围，比如数据层、控制层、视图层等。

3. 填写简短描述 (subject)：用一行文字简洁明了地描述这次提交的内容。

4. 填写详细描述 (body)：如果需要的话，详细描述这次提交的改动，使用"|"换行。

5. 是否是破坏性变更 (breaking)：如果是破坏性变更，请注明。

6. 是否影响某个 Issue (footer)：如果本次提交解决了某个 Issue，请在此注明。

此外，我们还可以在 package.json 的 scripts 中增加一个命令来执行 cz，这样就不需要每次都加 npx 了：

  "scripts": {
    "cz": "cz"
  },

然后执行npm run cz也是可以的

2. commitlint

使用 commitizen 提交代码后，我们可以确保提交信息的规范性，但如果有同事依然使用 git commit 提交代码，就可能导致提交信息的不规范。那么，如何强制大家只能通过 commitizen 提交代码呢？答案就是：使用 commitlint。

首先，我们需要安装 commitlint 和 @commitlint/config-conventional

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

包名	作用
@commitlint/cli	commitlint 的命令行工具，负责读取配置并执行提交信息校验。
@commitlint/config-conventional	官方提供的预设规则集（基于 Angular 提交规范），包含 feat/fix 等类型定义。

然后我们在根目录创建commitlint.config.js文件，配置commitlint

module.exports = {
  extends: ['@commitlint/config-conventional']
}

然后我们测试一下commitlint有没有生效

echo "随便改改" | npx commitlint  # 预期输出错误信息

输出

$ echo "随便改改" | npx commitlint  # 预期输出错误信息
⧗   input: 随便改改
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

说明 commitlint 配置成功，因为它不允许随便提交不规范的信息。

那我们这个怎么配合使用呢，就是在提交信息的时候触发这个npx commitlint ，看到这个是不是想起了我们的husky钩子呢，没错，我们的husky还提供了一个钩子是commit-msg，所以我们在husky文件夹下创建一个commit-msg文件，添加以下命令：

npx --no-install commitlint --edit $1

这个时候比如当我们团队有一个人这样子提交

git commit -m "修复了一个问题"   

这个时候触发我们的husky的钩子的commit-msg中的命令，我们的commitlint 就会先读取配置commitlint.config.js配置是@commitlint/config-conventional提交的信息要符合基于 Angular 提交规范这个规范的信息，如果不符合那么就会被打回来所以，上面的是不符合规范的就被打回来了

$ git commit -m "修复了一个问题"   
→ No staged files match any configured task.
⧗   input: 修复了一个问题
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky - commit-msg script failed (code 1)

所以我们就不能轻易的使用git commit提交了，那如果我们用npm run cz呢，答案是可以的因为我们的cz就是基于Angular 的规范提交的。

那如果我们用下面的这样一句呢

git commit -m "fix(login): 修复了一个问题" 

也是可以的这也符合，但是这样不方便，要自己手填而且要自己定义修改的type，所以我们还是用npm run cz 一开始规定好的提交规内容范交互式，快捷方便统一，效率更高。

3. commitlint-config-cz 和 cz-customizable

因为我们上面提交的信息是基于Angular 的提交规范的，有些开发者可能希望自定义提交规范，加入一些个性化的元素（比如表情等），那么，我们该如何解决这个问题呢？答案是，换一个 commitizen 的适配器。我们可以尝试将 cz-conventional-changelog 替换为 cz-customizable 自定义配置适配器 。但是，前面提到的 commitlint 也有规则校验，它是基于Angular 的预设规则集 @commitlint/config-conventional。所以，我们不仅要替换 commitizen 的适配器，还需要替换 commitlint 的规则配置。为此，我们需要使用 commitlint-config-cz，这是 commitlint 的 规则配置扩展包 ，用于将 cz-customizable 的自定义规则同步到 commitlint 中，确保两者的校验规则一致，避免 commitizen 和 commitlint 规则冲突，实现"一次配置，两端生效"。

所以我们先安装 commitlint-config-cz 和 cz-customizable

npm install commitlint-config-cz  cz-customizable -D

接着，在项目根目录创建一个.cz-config.js文件，并复制cz-config-EXAMPLE.js中的配置规则到里面。然后改成你自己想要的规则即可。

当然，你也可以用我写好的：

module.exports = {
  // 提交类型配置（必填）
  types: [
    { value: 'feat',     name: 'feat:     新功能' },
    { value: 'fix',      name: 'fix:      Bug修复' },
    { value: 'docs',     name: 'docs:     文档更新' },
    { value: 'style',    name: 'style:    代码格式调整（不影响功能）' },
    { value: 'refactor', name: 'refactor: 代码重构（非功能/非Bug）' },
    { value: 'perf',     name: 'perf:     性能优化' },
    { value: 'test',     name: 'test:     测试相关' },
    { value: 'chore',    name: 'chore:    构建流程或工具链变更' },
    { value: 'revert',   name: 'revert:   代码回退' },
    { value: 'init',     name: 'init:     项目初始化' },
    { value: 'build',    name: 'build:    构建系统或依赖变更' },
    { value: 'WIP',      name: 'WIP:     进行中的工作' }
  ],
  // 作用域配置（可选）
  scopes: [
    // 预定义常用作用域（可按需添加）
    // { name: 'auth' }, 
    // { name: 'api' }
  ],
  // 是否允许自定义作用域
  allowCustomScopes: true,
  // ---------------------------
  //   交互提示信息配置（中文化）
  // ---------------------------
  messages: {
    type: '请选择提交类型（必填）:', 
    scope: '请输入影响范围（可选）:',
    customScope: '请输入自定义影响范围:',
    subject: '请填写简短描述（必填/40字内）:',
    body: '长说明（可选/使用"|"换行）:\n',
    breaking: '非兼容性变更说明（可选）:\n',
    footer: '关联关闭的Issue（如 #123）:\n',
    confirmCommit: '确认提交？'
  },

  // ---------------------------
  //      提交规则配置
  // ---------------------------
  // 允许包含破坏性变更的类型
  allowBreakingChanges: ['feat', 'fix'],

  // 跳过的提问环节（简化流程）
  skipQuestions: ['scope', 'body', 'breaking'],

  // 描述文字长度限制
  subjectLimit: 40,

  // ---------------------------
  //     高级配置（按需启用）
  // ---------------------------
  // allowTicketNumber: false,               // 是否允许关联工单号
  // ticketNumberPrefix: 'TICKET-',          // 工单号前缀
  // ticketNumberRegExp: '\\d{1,5}',         // 工单号正则
  // breaklineChar: '|',                    // 长文本换行符
  // footerPrefix: 'ISSUES CLOSED:',         // Issue前缀
  // askForBreakingChangeFirst: true         // 优先询问破坏性变更
}

创建完这个文件之后，我们需要去 package.json 文件中，将 config.commitizen.path 更改为"node_modules/cz-customizable"如果你的.cz-config.js文件在项目根目录下，commitlint-config-cz 会自动在项目根目录下寻找你的cz-config.js文件配置

{
 "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"
    },
  }
}

如果不是在根目录的话那就需要指定的文件路径

{
  "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"
    },
    "cz-customizable": {
      "config": "你的文件路径/xxxconfig.js"
    }
  }
}

这里是更改了Commitzen的适配器，我们还要继续该Commitlint的规则

然后我们去commitlint.config.js中的文件进行更改 👇

module.exports = {
  // extends: ['@commitlint/config-conventional'],
  extends: ['cz']
}

到这里的时候我们再测试一下

git add .
npm run cz

控制台打印

[COMPLETED] *.{js,jsx,ts,tsx} --- 2 files
[COMPLETED] package.json --- 5 files
[COMPLETED] Running tasks for staged files...
[STARTED] Applying modifications from tasks...
[COMPLETED] Applying modifications from tasks...
[STARTED] Restoring unstaged changes to partially staged files...
[COMPLETED] Restoring unstaged changes to partially staged files...
[STARTED] Cleaning up temporary files...
[COMPLETED] Cleaning up temporary files...
[master 074604f] feat: 213
 5 files changed, 744 insertions(+), 2 deletions(-)
 create mode 100644 .cz-config.js

提交成功，perfect

总结：从混乱到规范，工程化带来的转变

经过我们上面一系列配置之后，代码变得更健壮了，整体开发流程也清晰多了，核心在于两个个阶段：

• pre-commit：通过 lint-staged 执行 eslint 和 prettier，保证每次提交前的代码格式和质量符合规范。
• commit-msg ：使用 commitlint 校验提交信息是否规范，避免出现git commit -m "更新了一点"等模糊提交记录。

完整自动化流程：

1. 修改代码 -> 自动格式化，确保代码风格一致。
2. 提交代码 -> 自动校验并生成规范化的提交信息，保持提交记录整洁。
3. 合并代码 -> 提前检查，避免格式冲突，确保代码始终保持一致。

通过引入工程化工具，不仅提升了代码的规范性，还极大改善了团队协作效率

• 避免无谓争论：风格统一，代码不再因为分号、缩进吵架。
• 降低维护成本：规范清晰，易于维护。
• 增强团队协作：每个人都能轻松接手和维护代码，避免重复劳动。

规范化不是束缚，而是高效协作的起点。 写代码不规范，同事两行泪？从今天开始，和"屎山代码"说再见吧！ 💪🚀