前端开发规范-Husky+Lint-Staged+Commitlint+ESLint+Prettier

用户971884103405
995 阅读4分钟

前端开发规范-Husky Lint-Staged Commitlint ESLint Prettier

在之前的文章已经介绍了 ESLint 和 Prettier 相关的配置并成功集成了两者。这边文章讲一下在 Git 上传代码时，对文件再次进行格式化和代码检查的操作，提升团队开发效率。

之前的相关文章可以直接点击阅读

ESLint && Prettier

ESLint

Prettier

直接讲操作

他们的功能随处搜一下都可以知道，这里就简单的讲一下如何配合使用，并讲一下我个人遇到的一些问题。

一、 首先安装依赖 lint-staged husky

二、 配置 huksy

在 package.json 中 "scripts"添加 "prepare": "husky", 这里是为了每次在 npm install时，让 huksy 在根目录生成对应的钩子文件,这里会有一个新的问题，比如前端项目不是根目录且.git 文件也不在此目录中，直接执行 huksy 会失败，所以要在子目录中调用 huksy

// 在子目录项目中 package.json
"scripts": {
    "prepare": "cd ../ && husky 子目录文件名/.husky",
}

cd 就是退到根目录 根据自己的目录情况来，husky 就是 husky 的命令 后面跟着子目录路径，并创建 .husky 文件夹

然后就会在前端项目根目录生成一个 .husky 文件夹

image.png

然后在 .husky 文件夹 下创建一个 pre-commit 的执行文件，看文件名就知道是在 git commit 时触发的，如果执行脚本失败， commit 也就不会成功 可以先通过 echo 来测试是否会调用

测试流程：

  1. git add .
  2. git commit -m 'test'
  3. 查看打印输出是否有自己想要的 echo
  4. 没有的话git就需要退回 执行 git reset --soft HEAD^
  5. 然后调整配置 再执行第二步，直到调试成功

image.png

image.png

图一是我 git commit 时的输出
图二是我的执行的代码
可以作为参考
这边提醒一下如果是子目录集成 husky 那在钩子执行文件中要从根目录进入子目录 比如图片中的 cd front 然后再调用你想执行的操作

三、配置 lint-staged

lint-staged 用于检查 git 暂存区 的文件，对其进行格式化和代码检查修改的操作。 在 package.json 中 添加 "lint-staged" 属性。可以根据文件类型执行对应的操作。比如对于js ts 先进行 prettier --write 格式化 再对其进行 eslint --fix 检查修复操作,对于 html css 就进行 prettier --write 格式化

// package.json
{
    "lint-staged": {
        "*.ts?(x)": [
            "prettier --write",
            "eslint --fix"
        ],
        "*.js?(x)": [
            "prettier --write",
            "eslint --fix"
        ],
        "*.html": [
            "prettier --write"
        ],
        "*.css": [
            "prettier --write"
        ]
    }
}

Lint-Staged 最常见的是用于 pre-commit 钩子中，以检查暂存区中的文件。但您也可以在其他 Git 钩子中使用它，并根据需要检查特定的文件。 Lint-Staged 的文件检查范围

  1. 暂存区中的文件：
    • 默认情况下，Lint-Staged 只会检查暂存区中的文件。这意味着它只会运行配置的任务来检查那些通过 git add 命令添加到暂存区的文件。
    • 这样可以确保只检查即将提交的文件，而不是整个项目。
  2. 非暂存区的文件：
    • 如果您希望检查非暂存区的文件，您可以在配置文件中指定文件路径或模式，或者在命令行中使用 -- 后跟文件路径来指定要检查的文件。

ESLint Prettier

四、配置 commitlint

commitlint 主要是检查 git commit -m 日志内容 是否符合规范，这里使用两个库 @commitlint/cli @commitlint/config-conventional

@commitlint/cli 一看就是命令行工具，可以读取 commitlint.config.js 配置文件， @commitlint/config-conventional 这里面就是内置了很多的规则，还有一个 parserPreset: 'conventional-changelog-conventionalcommits'

image.png

commitlint.config.js 基本配置

export default {
    ignores: [(commit) => commit === 'init'],
    extends: ['@commitlint/config-conventional'],
    rules: {
        'type-enum': [
            2,
            'always',
            ['feat', 'fix', 'docs', 'chore', 'style', 'refactor', 'test', 'revert'],
        ],
    },
};

配置好对应的 commitlint 后最重要的还需要监听 commit-msg 钩子. 在 .husky 文件夹下 创建commit-msg 文件 用于监听 commit 日志内容 ,同样 如果是子目录，要 cd 到相应的目录 然后执行 commitlint 的命令 --edit 传入的就是 -m 后面的日志消息内容

#!/usr/bin/env sh

cd front 
npx --no-install commitlint --edit "$1"

接下来就可以进行测试了

错误格式： 他就会提示报错信息，且 commit 失败

git commit -m 't'

image.png

正确格式： 这里就会成功 commit ，可以通过 git status 来查看是否提交成功

git commit -m 'feat: init'

image.png

rules 具体的配置可以看文档

commitlint 可以具体看一下介绍这里就简单使用

当然这里面还有一个 prompt，用于通过 cz-git 这个库来提交触发交互式的进行 commit ，这里就不介绍了，因为大多都是通过 git commit -m xxx 来进行提交代码，这样是不会触发的，如需要留言马上补充。

image.png

小小结

这里就基本上完成了从开发到提交代码的规范控制了，这配置不是固定的，按需求来更改。

avatar
文章
阅读
粉丝