ESLint

ESLint

标准的 ESLint 规则

// .eslintrc.js
// ESLint 配置文件遵循 commonJS 的导出规则，所导出的对象就是 ESLint 的配置对象
// 文档：https://eslint.bootcss.com/docs/user-guide/configuring
module.exports = {
    // 表示当前目录即为根目录，ESLint 规则将被限制到该目录下
    root: true,
    // env 表示启用 ESLint 检测的环境
    env: {
        // 在 node 环境下启动 ESLint 检测
        node: true
    },
    // ESLint 中基础配置需要继承的配置
    extends: ["plugin:vue/vue3-essential", "@vue/standard"],
    // 解析器
    parserOptions: {
        parser: "babel-eslint"
    },
    // 需要修改的启用规则及其各自的错误级别
    /**
     * 错误级别分为三种：
     * "off" 或 0 - 关闭规则
     * "warn" 或 1 - 开启规则，使用警告级别的错误：warn (不会导致程序退出)
     * "error" 或 2 - 开启规则，使用错误级别的错误：error (当被触发的时候，程序会退出)
     */
    rules: {
        "no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
        "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off"
    }
};

基于 ESLint 如果我们出现不符合规范的代码格式时，那么就会得到一个对应的错误。 但是一个团队中，成员的风格各不相同，大量的 ESLint 规则校验，会让很多的开发者头疼不已，从而大大影响了项目的开发进度。 试想一下，在你去完成项目代码的同时，还需要时时刻刻注意代码的格式问题，这将是一件多么痛苦的事情！ 那么有没有什么办法，既可以保证 ESLint 规则校验，又可以解决严苛的格式规则导致的影响项目进度的问题呢？ 答案是：Prettier

代码格式化工具：Prettier

1、一个代码格式化工具 2、开箱即用 3、可以直接集成到 VSCode 之中 4、在保存时，让代码直接符合 ESLint 标准（需要通过一些简单配置）

Prettier功能实现：

在 VSCode 中安装 prettier 插件（搜索 prettier），这个插件可以帮助我们在配置 prettier 的时候获得提示； 在项目中新建 .prettierrc 文件，该文件为 perttier 默认配置文件 配置

{
  // 不尾随分号
  "semi": false,
  // 使用单引号
  "singleQuote": true,
  // 多行逗号分割的语法中，最后一行不加逗号
  "trailingComma": "none"
}

打开VSCode，在设置中搜索 prettier，找到“Format On Save”选项，勾选上，保存，重启 VSCode 即可

但是只做到这样还不够，例如： VSCode 而言，默认一个 tab 等于 4 个空格，而 ESLint 希望一个 tab 为两个空格， 如果大家的 VSCode 安装了多个代码格式化工具， ESLint 和 prettier 之间的冲突问题

针对于这个问题我们想要解决也非常简单：

1、打开 .eslintrc.js 配置文件

2、在 rules 规则下，新增一条规则

'space-before-function-paren': 'off'

约定式提交规范

通过 prettier + ESLint 解决了代码格式的问题，但是我们之前也说过 编程规范 指的可不仅仅只是 代码格式规范 。 除了 代码格式规范 之外，还有另外一个很重要的规范就是 git 提交规范！

1、Commitizen助你规范化提交代码 commitizen 仓库名为 cz-cli ，它提供了一个 git cz 的指令用于代替 git commit。 当你使用 commitizen 进行代码提交（git commit）时，commitizen 会提交你在提交时填写所有必需的提交字段！ 2、全局安装Commitizen

npm install -g commitizen@4.2.4

3、安装并配置 cz-customizable 插件

npm i cz-customizable@6.3.0 --save-dev

4、添加以下配置到 package.json 中

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

5、项目根目录下创建 .cz-config.js 自定义提示文件

module.exports = {
  // 可选类型
  types: [
    { value: 'feat', name: 'feat:     新功能' },
    { value: 'fix', name: 'fix:      修复' },
    { value: 'docs', name: 'docs:     文档变更' },
    { value: 'style', name: 'style:    代码格式(不影响代码运行的变动)' },
    {
      value: 'refactor',
      name: 'refactor: 重构(既不是增加feature，也不是修复bug)'
    },
    { value: 'perf', name: 'perf:     性能优化' },
    { value: 'test', name: 'test:     增加测试' },
    { value: 'chore', name: 'chore:    构建过程或辅助工具的变动' },
    { value: 'revert', name: 'revert:   回退' },
    { value: 'build', name: 'build:    打包' }
  ],
  // 消息步骤
  messages: {
    type: '请选择提交类型:',
    customScope: '请输入修改范围(可选):',
    subject: '请简要描述提交(必填):',
    body: '请输入详细描述(可选):',
    footer: '请输入要关闭的issue(可选):',
    confirmCommit: '确认使用以上信息提交？(y/n/e/h)'
  },
  // 跳过问题
  skipQuestions: ['body', 'footer'],
  // subject文字长度默认是72
  subjectLimit: 72
}

6、使用 git cz 代替 git commit 使用 git cz 代替 git commit，即可看到提示内容

已经可以使用git cz 来代替了 git commit 实现了规范化的提交诉求了，但是当前依然存在着一个问题，那就是我们必须要通过 git cz 指令才可以完成规范化提交！ 如果有马虎的同事，它们忘记了使用 git cz 指令，直接就提交了怎么办呢？那么有没有方式来限制这种错误的出现呢？答案是Git Hooks

Git Hooks

整体的 hooks 非常多，当时我们其中用的比较多的其实只有两个： pre-commit：git commit执行前 ，它不接受任何参数，并且在获取提交日志消息并进行提交之前被调用。脚本git commit以非零状态退出会导致命令在创建提交之前中止。 （可以用git commit --no-verify绕过）

commit-msg：git commit执行前，可用于将消息规范化为某种项目标准格式。还可用于在检查消息文件后拒绝提交。（可以用git commit --no-verify绕过）

简单来说这两个钩子： commit-msg：可以用来规范化标准格式，并且可以按需指定是否要拒绝本次提交 pre-commit：会在提交前被调用，并且可以按需指定是否要拒绝本次提交

使用 husky + commitlint 检查提交描述是否符合规范要求

使用 git hooks 来去校验我们的提交信息，我们需要使用两个工具：

commitlint：用于检查提交信息

husky：是git hooks工具

（npm 需要在 7.x 以上版本）

commitlint：

安装依赖：

npm install --save-dev @commitlint/config-conventional@12.1.4 @commitlint/cli@12.1.4

创建 commitlint.config.js 文件

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

打开 commitlint.config.js

module.exports = {
  // 继承的规则
  extends: ['@commitlint/config-conventional'],
  // 定义规则类型
  rules: {
    // type 类型定义，表示 git 提交的 type 必须在以下类型范围内
    'type-enum': [
      2,
      'always',
      [
        'feat', // 新功能 feature
        'fix', // 修复 bug
        'docs', // 文档注释
        'style', // 代码格式(不影响代码运行的变动)
        'refactor', // 重构(既不增加新功能，也不是修复bug)
        'perf', // 性能优化
        'test', // 增加测试
        'chore', // 构建过程或辅助工具的变动
        'revert', // 回退
        'build' // 打包
      ]
    ],
    // subject 大小写不做校验
    'subject-case': [0]
  }
}

注意：确保保存为 UTF-8 的编码格式

husky

安装依赖：

npm install husky@7.0.1 --save-dev

启动 hooks ， 生成 .husky 文件夹

npx husky install

在 package.json 中生成 prepare 指令（ 需要 npm > 7.0 版本 ）

npm set-script prepare "husky install"

执行 prepare 指令

npm run prepare

添加 commitlint 的 hook 到 husky中，并指令在 commit-msg 的 hooks 下执行 npx --no-install commitlint --edit "$1" 指令

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

通过 pre-commit 检测提交时代码规范

在 ESLint 与 Prettier 配合解决代码格式问题 的章节中，我们讲解了如何处理 本地！代码格式问题。

但是这样的一个格式处理问题，他只能够在本地进行处理，并且我们还需要 手动在 VSCode 中配置自动保存 才可以。那么这样就会存在一个问题，要是有人忘记配置这个东西了怎么办呢？他把代码写的乱七八糟的直接就提交了怎么办呢？

所以我们就需要有一种方式来规避这种风险。

那么想要完成这么一个操作就需要使用 husky 配合 eslint 才可以实现。

我们期望通过 husky 监测 pre-commit 钩子，在该钩子下执行 npx eslint --ext .js,.vue src 指令来去进行相关检测：

执行 npx husky add .husky/pre-commit "npx eslint --ext .js,.vue src" 添加 commit 时的 hook （npx eslint --ext .js,.vue src 会在执行到该 hook 时运行）

该操作会生成对应文件 pre-commit：

关闭 VSCode 的自动保存操作

修改一处代码，使其不符合 ESLint 校验规则

执行 提交操作 会发现，抛出一系列的错误，代码无法提交

想要提交代码，必须处理完成所有的错误信息

lint-staged 自动修复格式错误

通过 pre-commit 处理了 检测代码的提交规范问题，当我们进行代码提交时，会检测所有的代码格式规范 。

但是这样会存在两个问题：

我们只修改了个别的文件，没有必要检测所有的文件代码格式

它只能给我们提示出对应的错误，我们还需要手动的进行代码修改

想要处理这两个问题，就需要使用另外一个插件 lint-staged ！

lint-staged 可以让你当前的代码检查 只检查本次修改更新的代码，并在出现错误的时候，自动修复并且推送

lint-staged 无需单独安装，我们生成项目时，vue-cli 已经帮助我们安装过了，所以我们直接使用就可以了

修改 package.json 配置

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

如上配置，每次它只会在你本地 commit 之前，校验你提交的内容是否符合你本地配置的 eslint规则(这个见文档 ESLint )，校验会出现两种结果：

如果符合规则：则会提交成功。 如果不符合规则：它会自动执行 eslint --fix 尝试帮你自动修复，如果修复成功则会帮你把修复好的代码提交， 如果失败，则会提示你错误，让你修好这个错误之后才能允许你提交代码。

再次执行提交代码

发现 暂存区中 不符合 ESlint 的内容，被自动修复