【前端工程化】配置文件

ESLint 核心知识整理

功能：静态代码分析工具，专门用于JavaScript和JSX代码的校验。它可以在没有任何程序执行的情况下，对代码进行分析
原理：静态分析（通过 AST解析代码，检查是否符合规则）

一、核心配置项

1. rules

• 作用：定义具体规则，值为 0（off）、1（warn）、2（error）。

• 示例：

  • 强制单引号
  • 强制 2 空格缩进

2. extends

• 作用：合并他人编写的配置（如官方推荐或社区配置）。

• 推荐配置：

  • JavaScript：eslint:recommended
  • TypeScript：@typescript-eslint/recommended

3. plugins

• 作用：引入自定义规则插件。

• 示例：

  • React Hooks 插件：react-hooks，确保遵循 Hooks API 规范。

二、配置文件

• 格式与优先级：

  • package.json（权重最低） < .eslintrc.yaml/.eslintrc.cjs < .eslintrc.js（ESLint 8.x） < eslint.config.js（ESLint 9.x，权重最高）。

• 配置优先级
  extends>plugin>rules

三、集成到构建工具

1. 集成到 Vite

• 步骤：

  1. 安装 ESLint 并配置规则。
  2. 安装插件：npm install vite-plugin-eslint --save-dev。

四、特点

• 插件化：ESLint是一个插件化的代码检查工具，可以利用插件来解析各种文件，如使用eslint-plugin-vue来检测Vue文件，使用eslint-plugin-react来检测JSX文件。

• 自动修复：部分错误ESLint可以自动修复。在ESLint命令后面跟上--fix参数，ESLint将会尝试自动修复基础错误。

• 灵活配置：ESLint提供了丰富的配置选项，允许开发人员根据项目需求自定义规则、风格和检查项。

Pretitter核心知识整理

功能： 用来统一代码格式，eslint也会对代码进行一定程度的格式校验，但主要是用来对代码规范的扫描，而prettier则是专门用来对代码进行格式化。它的主要原理是将格式化前的代码和格式化后的代码进行比对，如果发现不一样，prettier就会对其进行标记并按照指定的格式化规范进行修复
原理：

1. 解析代码为 AST。
2. 按照配置规则重新生成代码，而非基于正则替换

• ESLint：

  配置较为复杂，可以通过.eslintrc.js文件或者eslint.config.js文件配置规则，也可以在项目的package.json文件中添加eslintConfig字段进行配置。

• Prettier：

  配置相对简单，只需要在项目根目录下创建.prettierrc.js文件或者.prettierrc.json来设置一些基本的格式化选项

lint-staged核心知识整理

功能：对 git暂存区 代码进行处理的工具，使用eslint和husky能够保证代码的质量问题，但是会存在每次修改一个文件，会对所有文件执行一次lint检查，所以lint-staged的主要功能就是每次只对当前修改后的文件进行扫描

一、核心配置项

"scripts": {
    "precommit": "lint-staged"
},
"lint-staged": {
    "src/**/*.js": [
        "eslint --fix --ext .js",
        "prettier --write",
        "git add"
    ]
},

配置解析

• src/**/*.js：匹配 src 目录下所有 .js 文件。

• 命令链：

  1. eslint --fix --ext .js：使用 ESLint 自动修复代码风格问题（如缩进、引号等）。
  2. prettier --write：使用 Prettier 格式化代码（覆盖与 ESLint 冲突的规则）。
  3. git add：将修复后的文件重新添加到暂存区，确保提交的是已格式化的代码

工作流程示例

1. 修改 src/module.js 并执行 git add module.js。
2. 执行 git commit 时，触发 precommit 钩子，运行 lint-staged。
3. lint-staged 只对 module.js 执行 ESLint + Prettier 检查和修复。
4. 若修复成功，自动提交格式化后的代码；若存在无法自动修复的错误（如未定义变量），则阻止提交并提示错误。

git hooks

功能

git内置的机制，在特定的git操作前后执行自定义脚本，这些脚本就是hooks(钩子)，用于校验代码或者触发自动化任务

常见客户端钩子

• pre-commit：提交前触发，可用于代码检查。
• commit-msg：验证提交信息格式。
• pre-push：推送前触发，可用于运行测试。

原生实现

• Git 钩子脚本存放在代码仓库的 .git/hooks/ 目录下，文件名对应钩子类型（如 pre-commit.sample）。

• 步骤：

  1. 复制示例脚本（去掉 .sample 后缀），如 cp .git/hooks/pre-commit.sample .git/hooks/pre-commit。
  2. 修改脚本为可执行文件：chmod +x .git/hooks/pre-commit。
  3. 编写脚本逻辑（如用 Shell 脚本执行 ESLint）。

• 缺点：

  • 钩子脚本存于本地 .git 目录，无法通过 Git 提交分享给团队成员。
  • 手动管理脚本繁琐，难以维护复杂逻辑。

husky

一、核心功能

拦截 Git 操作
在 commit、push 等关键节点触发脚本，例如：

• 提交前自动执行 ESLint/Prettier 检查。
• 推送前运行单元测试。
• 验证提交信息格式（如 Conventional Commits 规范）

二、原理

劫持原生 Git Hooks，并将其指向项目内的可执行脚本

1. 初始化阶段
   执行 npx husky install 时，Husky 会：

   • 在项目根目录创建 .husky 文件夹，用于存放钩子脚本。
   • 修改 .git/config（插件自动修改），将 Git Hooks 路径指向 .husky。

2. 钩子触发阶段
   当执行 git commit 时：

   • Git 会查找 .husky/pre-commit 脚本并执行。
   • 该脚本通常调用 npm 命令（如 npx lint-staged），对代码进行检查或格式化。
   • 若脚本返回非零状态码（表示失败），Git 操作将被终止。

三、实际场景

• 搭配 ESLint + Prettier

{
  "scripts": {
    "lint": "eslint src --fix"
  },
  "lint-staged": {
    "src/**/*.js": ["prettier --write", "git add"]
  }
}

.husky/pre-commit 脚本：

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

npx lint-staged

• 验证提交信息格式（CommitLint）

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

commitLint核心知识整理

功能：校验git提交信息格式的工具，确保团队成员遵循统一的提交规范

一、核心配置项

配置文件：.commitlintrc.js

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    // 自定义规则示例
    'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']], // 允许提交的类型
    'subject-case': [0], // 不强制主题大小写
  },
};

二、集成到husky

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'
此命令会在 .husky/commit-msg 中生成脚本，校验提交信息文件（$1）。

三、提交规范格式

feat(auth): 添加登录验证