前言

又抓住了11月的尾巴来更新文章了，今天想写一写关于工作中是如何实践前端标准规范化工作流的。

我们前端开发人员有7个左右，每个人的风格不一样，可想而知，如果没有标准代码提交规范，那可真是各色代码鱼龙混杂。思考过这个问题吗，只要放慢脚步，不再只关注于手头的工作，想想如果让你怎么去解决这个问题呢？😶‍🌫️

聚焦问题的中心，想想实现的目标是什么？💡

代码提交前按照规则格式化、语法校验，存在错误不再提交到仓库；
commit msg清晰，言简意赅，核心描述此次提交的内容；
每次发版可以生成changelLog，帮助查找每次迭代的更新内容；
最好每次提交前自动帮助我们做以上的工作，且具有强制性；

接下来的文章，不会具体讲解每个工具是如何使用，会将重点说明，它们->如何能帮助我们实践标准规范化的工作流。

husky

是不是任意一篇文章点开，就离不开这个主角呢？husky是结合git hooks实现在各种钩子中添加自定义命令，如test、eslint、commitlint等处理，官网上的一句描述了他的feature. 官网链接在这里

You can use it to lint your commit messages, run tests, lint code, etc… when you commit or push. Husky supports all Git hooks.

根据官网上的指导，就先初始化一个项目吧！

npm init // 初始化项目，并生成package.json
git init // 既然husky结合的是git hooks，当然要使用git管理仓库了

接着往下，开始使用husky的魔法了

npx husky-init // modify `package.json` and create a sample `pre-commit` hook that you can edit. By default, it will run `npm test` when you commit.

这条命令执行后，会修改package.json文件，并新增一条命令，"prepare": "husky install". 当前目录下也会生成.husky文件夹，用来存储使用的git-hooks命令.默认会有一条pre-commithook，代表在提交commit之前会执行. 后续里面的命令我们会替换成其他的。

continue，接着我们下载依赖，并添加一条commit-msghook，用来校验commit信息是否符合commitlint的规范。

yarn // 开始下载依赖
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ""' // add another hook

lint-staged

如果使用eslint等代码校验工具，在每次保存或提交全局校验代码耗时就会非常长，而且如果别人的代码有错误影响提交，自己也不好去修改，万一下次就有冲突呢😶‍🌫️

lint-staged仅会对Git暂存区进行过滤符合我们设定条件的文件，eslint、prettier等再去格式化代码操作。

安装

npm install -D lint-staged

修改package.json的配置

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "prepare": "husky install",
    "lint": "eslint . --ext js,jsx,ts,tsx,vue --fix"
 },
"lint-staged": {
    "src/*.{js,jsx,ts,tsx}": "npm run lint", // eslit校验，我这里都是配置的对src目录下所有符合条件的文件进行过滤
    "src/*.{js,jsx,tsx,ts,less,md,json}": [
      "npx prettier --write", // prettier格式化
      "git add"
    ]
  }

修改husky中pre-commithook的命令，即在提交前会执行lint-staged.

eslint

安装eslint相关依赖

npm install -D eslint eslint-config-prettier eslint-plugin-prettier eslint-plugin-vue

配置.eslintrc.js文件

module.exports = {
  env: {
    browser: true,
    es2021: true
  },
  extends: [
    'plugin:vue/vue3-recommended',
    'plugin:vue/vue3-essential',
    'plugin:prettier/recommended', // eslint-plugin-prettier 会将 prettier 作为 ESLint 的规则来使用，相当于代码不符合 Prettier 的标准时，会报一个 ESLint 错误，同时也可以通过 eslint --fix 来进行格式化
    'prettier' // eslint-config-prettier 解决eslint与prettier的冲突，写在最后面会覆盖冲突的eslint规则
  ],
  overrides: [],
  parserOptions: {
    ecmaVersion: 'latest',
    sourceType: 'module'
  },
  plugins: ['eslint-plugin-vue'], // 项目vue框架的化，这个插件会提供vue/vue3-essential、vue/vue3-recommended等校验规则
  rules: { // 放置自定义规则
    'no-unused-vars': 'error',
    'no-console': 'error'
  }
}

prettier

安装

npm install -D prettier

配置.prettierrc文件，我这里配置的很简单，可以根据需要添加

{
  "semi": false,
  "tabWidth": 2, // tab长度为2
  "trailingComma": "none", // 句末分号
  "singleQuote": true, // 单引号
  "arrowParens": "avoid"
}

commitlint

commitlint是用来规范提交信息的，规范的信息可以用来生成changeLog，在husky的commit-msghook里已经增加了commitlint命令，提交后会对我们输入的信息进行校验，如果不符合规范commit-msghook会抛出错误，commit会停止。

安装

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

配置commitlint.config.js文件

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

commitlint是有提交格式的，

git commit -m <type>[optional scope]: <description>

// 举个例子，如果我修改了一个bug，我会这么写
fix/(@gcbp/web-framework): 修复下拉选展示异常

常用的type如下：

build 编译相关的修改，例如发布版本、对项目构建或者依赖的改动
chore 其他修改, 比如改变构建流程、或者增加依赖库、工具等
ci 持续集成修改
docs 文档修改
feat 新特性、新功能
fix 修改bug
perf 优化相关，比如提升性能、体验
refactor代码重构
revert回滚到上一个版本
style代码格式修改, 注意不是 css 修改
test测试用例修改

总结

到目前为止，回顾开头的目标，我们使用了husky管理git hooks强制性在提交文件阶段做了两件事，在commit-msghook使用commitlint规范commit信息，并且有严格清晰的格式规则；在pre-commithook使用lint-stages将暂存区文件，小范围内进行格式化，使用eslint校验代码，prettier格式化代码，保证参与项目每个人的代码风格一致。

可以尝试按照文章的步骤从0开始，看看效果吧，这样记忆会更加深刻💕

参考文章：
# 用 husky 和 lint-staged 构建代码检查工作流

文章版权归作者所有，未经允许请勿转载。

THE END