ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

使用 @commitlint/config-angular 以 Angular 提交规范约束 Git 提交信息

使用 @commitlint/config-angular 以 Angular 提交规范约束 Git 提交信息 开发工具Lint代码质量【免费下载链接】commitlint Lint commit messages项目地址https://gitcode.com/gh_mirrors/co/commitlint点击查看免费下载commitlint/config-angular是 commitlint 官方维护的 shareable config可共享配置它将 [Angular 社区提交规范] 固化为一套可直接使用的规则集与 commitlint/cli 和 commitlint/prompt-cli 配合即可完成提交信息的自动校验。读完本文你将掌握该配置的安装接入方式、其中每一条规则的判定逻辑与严重级别、底层解析与执行原理以及如何基于它做二次自定义。什么是commitlint/config-angularcommitlint 本身只是一个规则引擎它负责把提交信息解析成结构化字段再逐条执行规则并汇总错误与警告见 lint.ts但应该遵守什么规范由配置决定。commitlint/config-angular就是一个把 Angular 提交约定固化为 12 条规则的 shareable config通过extends字段被业务项目引用后这些规则便会自动生效。该包的核心实现非常精简完整内容见 index.js它只做两件事——定义一个parserPreset告诉解析器如何切分提交信息和一组rules定义校验规则其余交给 commitlint 引擎执行。快速开始安装与接入按照 README 中的指引两步即可完成接入npm install --save-dev commitlint/config-angular commitlint/cli echo export default {extends: [commitlint/config-angular]}; commitlint.config.js第一条命令同时安装校验引擎与 Angular 规则集第二条命令在当前项目根目录生成commitlint.config.js通过extends字段声明继承该 shareable config。之后即可使用 commitlint 校验提交信息例如# 通过校验退出码为 0 echo fix: some message | npx commitlint # 校验失败退出码非 0 echo foo: some message | npx commitlintextends的解析由commitlint/load包负责它支持递归 extends、本地文件、npm 包等多种解析方式仓库中 load 目录 下有完整的解析实现与丰富用例。由于本包声明type: module且main指向 index.js见 package.json在 ESM 项目中可被直接import。提交信息如何被解析parserPreset 与 headerPatterncommitlint/config-angular配置了自定义解析器预设parserPreset: { parserOpts: { headerPattern: /^(\w*)(?:\((.*)\))?!?: (.*)$/ }, },这个正则把提交信息的首行header拆解为三个部分捕获组含义对应字段(\w*)单词字符组成的提交类型type(?:\((.*)\))?可选的括号作用域scope(.*)冒号之后的主题描述subject例如fix(scope): some message会被解析为type fix、scope scope、subject some message。解析动作由 commitlint/parse 完成它内部使用conventional-commits-parser并会把type、scope、subject缺失时归一为null随后 lint 引擎基于这些字段执行规则见 lint.ts 中对parsed的消费。正则中虽然允许!!?:部分但规则层通过subject-exclamation-mark明确禁止了这种写法详见下文。规则总览Problems 与 Warnings 两级体系commitlint 中每条规则的配置是三元组[level, when, value]level严重级别0关闭、1警告warning、2错误error。级别校验逻辑见 lint.ts级别不在0~2或条件不是always/never时都会抛出配置错误级别为0的规则被直接跳过级别2的不满足项计入errors级别1的不满足项计入warnings最终valid errors.length 0即只要存在错误级不满足项CLI 就会返回非零退出码。when判定条件always必须满足或never必须不满足。value判定参数如枚举列表、大小写风格、长度上限等。commitlint/config-angular的 12 条规则中9 条为 Problems错误级不满足即校验失败3 条为 Warnings警告级仅提示。下表为 index.js 中的完整规则声明规则级别whenvaluesubject-exclamation-mark2never—body-leading-blank1always—footer-leading-blank1always—header-max-length2always72scope-case2alwayslower-casesubject-case2never[sentence-case, start-case, pascal-case, upper-case]subject-empty2never—subject-full-stop2never.type-case2alwayslower-casetype-empty2never—type-enum2always见下节必须满足的规则Problems级别 2以下规则不满足时会产生错误并导致提交校验失败退出码非零。type-enum类型必须在允许枚举内条件type出现在 value 枚举中规则always值[build, ci, docs, feat, fix, perf, refactor, revert, style, test]echo foo: some message # fails echo fix: some message # passes有意思的是这份枚举并不直接写死在本包中而是从独立的 commitlint/config-angular-type-enum 包导入type-enum: typeEnum.rules[type-enum]。该包以单一路径维护 Angular 类型枚举其实现为[2, always, types]供多个配置包复用避免重复维护。底层判定由 type-enum.ts 调用 enum.ts 完成——本质是一个白名单检查enums.indexOf(value) -1当type缺失时该规则直接放行交由type-empty负责。type-case类型必须小写条件type处于value指定的大小写风格规则always值lowerCaseecho FIX: some message # fails echo fix: some message # passestype-empty类型不能为空条件type为空规则neverecho : some message # fails echo fix: some message # passesscope-case作用域必须小写条件scope处于value指定的大小写风格规则always值lowerCaseecho fix(SCOPE): some message # fails echo fix(scope): some message # passessubject-case主题禁用特定大小写风格条件subject处于[sentence-case, start-case, pascal-case, upper-case]中的任一种规则neverecho fix(SCOPE): Some message # fails echo fix(SCOPE): Some Message # fails echo fix(SCOPE): SomeMessage # fails echo fix(SCOPE): SOMEMESSAGE # fails echo fix(scope): some message # passes echo fix(scope): some Message # passes注意最后一行some Message并不属于被禁的四种风格因此通过校验。该规则的实现 subject-case.ts 有个细节只有当 subject 首字符是 Unicode 大小写字母\p{Ll}\p{Lu}\p{Lt}时才执行大小写判定从而兼容非拉丁字母语言的提交信息。subject-empty主题不能为空条件subject为空规则neverecho fix: # fails echo fix: some message # passessubject-full-stop主题不能以句号结尾条件subject以value结尾规则never值.echo fix: some message. # fails echo fix: some message # passessubject-exclamation-mark禁止用!标记破坏性变更条件subject不得在:标记前包含!规则neverAngular 提交规范不使用!来声明破坏性变更breaking change因此该配置将其禁用。对应测试见 index.test.jstest!: with a breaking change in the type与test(scope)!: ...均会产生错误subject must not have an exclamation mark in the subject to identify a breaking change。如果你的团队希望使用 Conventional Commits 风格的!README 建议改用 commitlint/config-conventional。header-max-lengthheader 长度上限 72 字符条件header不超过value个字符规则always值72echo fix: some message that is way too long and breaks the line max-length by several characters # fails echo fix: some message # passes该规则实现 header-max-length.ts 直接测量parsed.header的字符数超过即失败。测试用例中 79 字符的 header 会得到错误header must not be longer than 72 characters, current length is 79。警告级规则Warnings级别 1以下规则不满足时仅输出警告信息不会导致校验失败。body-leading-blank正文前必须有空行条件Body 以空行开始规则always即 header 与正文之间必须保留一个空行。对应的测试用例index.test.js展示了 header 后直接接正文会产生警告body must have leading blank line。footer-leading-blank页脚前必须有空行条件Footer 以空行开始规则always与上一条同理footer如BREAKING CHANGE:、Reviewed-by:等 trailer之前必须有一个空行与正文分隔。结合测试用例验证整体行为仓库自带的 index.test.js 通过commitlint/lint的lint(message, rules, { parserOpts })接口对配置做了端到端验证可作为理解规则协作方式的范例test: a valid angular commit、test(scope): a valid angular commit with a scope、带正文的多行提交 →valid: true且errors与warnings均为空no: no is not an invalid commit type→ 因type-enum失败报错type must be one of [build, ci, docs, feat, fix, perf, refactor, revert, style, test]超长 header → 因header-max-length失败带!的 header → 因subject-exclamation-mark失败。这印证了三条规则之间的配合关系type-enum在type缺失时放行而type-empty专门兜底空类型subject-case只在 subject 以字母开头时生效。整体设计让每条规则职责单一、可独立理解。基于该配置进行自定义extends继承的规则可以在项目中按需覆盖。由于规则三元组中level 0表示关闭lint.ts 中config[0] 0才会执行常见的自定义方式包括export default { extends: [commitlint/config-angular], rules: { // 放宽 header 长度上限到 100 header-max-length: [2, always, 100], // 追加自定义类型需与 type-enum 白名单一致 type-enum: [2, always, [build, ci, docs, feat, fix, perf, refactor, revert, style, test, chore]], // 关闭某条警告 body-leading-blank: [0], }, };若想了解全部可用规则及其参数语义可查阅 规则参考文档配置文件的更多写法如函数式配置、异步配置、extends解析细节见 配置指南。将配置接入 Git 钩子husky即可实现提交前自动校验具体步骤可参考 本地接入指南。小结commitlint/config-angular用 12 条规则完整固化了 Angular 提交约定9 条错误级规则类型枚举/大小写/非空、作用域大小写、主题大小写/非空/禁句号/禁!、header 长度保证提交结构合规2 条警告级规则正文与页脚前的空行维持可读性。其实现以精简配置 引擎执行为哲学配置只声明解析预设与规则三元组判定逻辑全部复用 commitlint/rules 与 commitlint/ensure 的通用实现并通过config-angular-type-enum独立维护类型枚举。理解它的规则模型后你既能开箱即用也能按团队规范自由增删规则。赞分享开发工具Lint代码质量【免费下载链接】commitlint Lint commit messages项目地址https://gitcode.com/gh_mirrors/co/commitlint点击查看免费下载相关推荐Angular项目Git提交信息规范详解Angular项目Git提交信息规范详解 前言 在大型开源项目中规范的提交信息格式对于项目管理至关重要。Angular作为前端主流框架其提交信息规范经过精心前端Web框架使用 Lefthook 集成 commitlint 与 commitizen规范 Git 提交信息的完整实战指南使用 Lefthook 集成 commitlint 与 commitizen规范 Git 提交信息的完整实战指南 commitlint 与 commitize开发工具使用 lefthook 集成 commitizen 与 commitlint构建规范化的 Git 提交信息工作流使用 lefthook 集成 commitizen 与 commitlint构建规范化的 Git 提交信息工作流 本指南基于 lefthook 官方示例文档开发工具创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表