前端代码风格自动化系列（二）之Commitlint

FuisonDesign 发布于2019-08-23 14:33 / 2849人阅读

摘要：文件配置配置说明由和配置数组组成，如，数组中第一位为，可选，为，为，为，第二位为应用与否，可选，第三位该的值。

在有了Husky赋能之后，我们有能力在Git的钩子里做一些事情，首先不得不提的是代码的提交规范和规范的校验，优雅的提交，方便团队协作和快速定位问题。首推Commitlint，另外@加神推荐了Gitmoji也是一个很有意思的工具。

安装

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

// 生成配置文件commitlint.config.js，当然也可以是 .commitlintrc.js
echo "module.exports = {extends: ["@commitlint/config-conventional"]};" > commitlint.config.js

配置

在husky的配置加入CommitlIint配置，v1.0.1版本以后为HUSKY_GIT_PARAMS，v0.14.3为GIT_PARAMS

"husky": {
    "hooks": {
      "pre-commit": "npm run test",
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  },

定制提交规范 提交格式（注意冒号后面有空格）

常用的type类别

upd：更新某功能（不是 feat, 不是 fix）

feat：新功能（feature）

fix：修补bug

docs：文档（documentation）

style：格式（不影响代码运行的变动）

refactor：重构（即不是新增功能，也不是修改bug的代码变动）

test：增加测试

chore：构建过程或辅助工具的变动

例子：

git commit -m "feat: 增加 xxx 功能"
git commit -m "bug: 修复 xxx 功能"

subject

subject是 commit 目的的简短描述，可以做一些配置，如最大长度限制。

commitlint.config.js文件配置

rule配置说明:：rule由name和配置数组组成，如："name:[0, "always", 72]"，数组中第一位为level，可选0,1,2，0为disable，1为warning，2为error，第二位为应用与否，可选always|never，第三位该rule的值。具体配置例子如下：

module.exports = {
  extends: [
    "@commitlint/config-conventional"
  ],
  rules: {
    "type-enum": [2, "always", [
      "upd", "feat", "fix", "refactor", "docs", "chore", "style", "revert"
     ]],
    "type-case": [0],
    "type-empty": [0],
    "scope-empty": [0],
    "scope-case": [0],
    "subject-full-stop": [0, "never"],
    "subject-case": [0, "never"],
    "header-max-length": [0, "always", 72]
  }
};

这里列出了大部分常用的配置，其它的可以参考Commitlint网站，具体使用例子：

这里我们使用错误的提交方式，最上面的是自动测试的脚本，大家可以忽略，husky给出了commit-msg的input为xxx，触发了subject-empty，type-empty两个规则，提交不符合规范，被拦了下来。如果是正确的提交，例子如下：

关于Commitlint的使用就到这里了。

GPU云服务器云服务器系列之系列之二架构之坑系列代码风格

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/100778.html

前端代码风格自动化系列（五）之共同出击

摘要：我们在前面的四篇中介绍了这些工具，可以完成以最小的代价在提交到远程仓库前，格式化为统一风格的代码，大家都很熟悉这里就不列举了。下面举一个配置。这里对于项目里分别做了提交前格式化操作，对于提交规范做了校验。我们在前面的四篇中介绍了husky、commitlint、lint-staged、prettier这些工具，可以完成以最小的代价在Git提交到远程仓库前，格式化为统一风格的代码，es...

pumpkin9 2019-08-23 14:33 评论0 收藏0
前端代码风格自动化系列（三）之Lint-staged

摘要：在我们介绍了之后，来看一个前端文件过滤的工具，代码的格式化肯定会涉及到文件系统，一般工具会首先读取文件，格式化操作之后，重新写入。在我们介绍了Husky、Commitlint之后，来看一个前端文件过滤的工具Lint-staged，代码的格式化肯定会涉及到文件系统，一般工具会首先读取文件，格式化操作之后，重新写入。对于较大型的项目，文件众多，首先遇到的就是性能问题，虽然如Eslint之...

zzir 2019-08-23 14:33 评论0 收藏0
如何文明提交代码

摘要：程序员最烦的几件事写测试，变量命名，还有填代码提交信息。其实的作用远不止如此，经过简单的配置便可无痛成为代码提交的文明公民。好的提交历史可以方便其他人参与进来，也可以方便自己快速定位问题。程序员最烦的几件事：写测试，变量命名，还有填代码提交信息（commit message）。翻几个开源项目遍马上可以回味那作文凑字数的青春时光。其实 commit message 的作用远不止如此，...

BaronZhang 2019-08-23 12:07 评论0 收藏0
工程搭建---代码风格统一

摘要：为此我们需要安装这个是用于提交代码的钩子函数安装完之后，我们就需要在增加运行钩子函数。等钩子函数这样就简单的成功对代码进行效验了，当然这边更进一步的可以使用这个可以将取得所有被提交的文件依次执行写好的任务。一个项目是会有多个成员来开发的，因此统一开发规范是很有必要的，不然每个人都有自己的风格，同步之后代码都会报错。我这边是用Vscode编译器的。首先用vue-cli3.0创建一个工...

levius 2019-08-23 16:05 评论0 收藏0
代码风格统一：commitlint & eslint & standard-vers

摘要：配置添加包配置此处如果不使用需要将替换为效果代码提交的格式不符合标准就会直接被拒绝。 Commitlint 配置添加包 yarn add @commitlint/cli @commitlint/config-conventional husky -D 配置package.json husky: { hooks: { // 此处如果不使用husky 需要将H...

lieeps 2019-08-23 13:54 评论0 收藏0