Suggestion: sub-typing to handle overlapping types, meta-types and fine-grained scope #135

New Issue

GiteaMirror · 2026-02-17T11:48:53-06:00

GiteaMirror commented

2026-02-17 11:48:53 -06:00

Originally created by @Zorvalt on GitHub (Oct 19, 2021).

I am just starting to use Conventional Commits so my idea might be out of scope. Those examples might be inadequate due to my lack of experience, then could it still apply in other cases?

Context

I made a simple change to a build script (responsible for building only a part of the code base) in order to increase readability and maintenance. I splat a list of CFLAGS inside a Makefile in two lists to clarify which flags are required and which are "additional" (debug, etc.).

I was wondering if this should be a doc or a build change. I was hesitating between messages similar to:

build(ModuleA): Clarify which CFLAGS are required or optional [...]
doc(ModuleA): Clarify which CFLAGS are required or optional in the build [...]

I came to the conclusion that I changed the doc (type) of the build within the scope ModuleA. So, in my case, I think the build type is a kind of sub-type.

Suggestion

Goal

Allow a reader to understand some ambiguous types or scopes without having to read more than the type/scope part.

Few syntax candidates to illustrate

I thought of the following syntax candidate but my point is not on how to update the grammar but only whether it improves Conventional Commits or not.

Expected meaning: "I updated the doc... impacting build(ModuleA)

doc::build(ModuleA): Clarify which CFLAGS are required or optional [...]
Expected meaning: "I documented the build relative to scope ModuleA

doc(build:ModuleA): Clarify which CFLAGS are required or optional [...]
Expected meaning: "I updated the build relative to scope doc in ModuleA

build(doc:ModuleA): Clarify which CFLAGS are required or optional [...]

Use cases and reach

What do you think about adding the possibility to specify that? This can cover a lot more such as:

refactor in order to fix
fix a test
refactor the ci pipelines
perf improvement in scope ModuleC of repoB in a monorepo
revert a feat
etc.

Of course, if you refactor the ci pipelines, you refactored and the remainder could go in the description, the body or the footer. The sub-typing does not resolve something impossible but, in my opinion, extends and add clarity to the scope.

Sub-typing also allows more fine grained scopes for monorepos by allowing some kind of scope hierarchy, In both of my commit messages compliant with Conventional Commits 1.0.0, someone has to read the description to understand the real scope of my commit. I believe this illustrates a small gap in the scope syntax.

Finally, sub-typing naturally allows meta-types such as:

revert type whose sub-type would be the reverted type
wip type whose sub-type would be the final type (wip:fix, wip:feat, etc.)

Drawbacks

What should be the maximal sub-type depth ?

Maybe I updated the style of the doc of the build in the scope of ModuleA... and I could go on if I wanted to be creative. I think this would follow the semantics of the angular guidlines but is clearly a worse choice than a type overlap.

Meaningless sub-types

Although this could be suppressed by simply applying common sense, sub-typing introduces the possibility to revert a fix or style a refactor. I think this is not a real concern but I mention it to maybe open the discussion to more concerning issues.

edit: typos

Originally created by @Zorvalt on GitHub (Oct 19, 2021). I am just starting to use Conventional Commits so my idea might be out of scope. Those examples might be inadequate due to my lack of experience, then could it still apply in other cases? # Context I made a simple change to a build script (responsible for building only a part of the code base) in order to increase readability and maintenance. I splat a list of CFLAGS inside a Makefile in two lists to clarify which flags are required and which are "additional" (debug, etc.). I was wondering if this should be a `doc` or a `build` change. I was hesitating between messages similar to: - build(ModuleA): Clarify which CFLAGS are required or optional [...] - doc(ModuleA): Clarify which CFLAGS are required or optional in the build [...] I came to the conclusion that I changed the `doc` (type) of the `build` within the scope `ModuleA`. So, in my case, I think the `build` type is a kind of sub-type. # Suggestion ## Goal Allow a reader to understand some ambiguous types or scopes without having to read more than the type/scope part. ## Few syntax candidates to illustrate I thought of the following syntax candidate but my point is not on how to update the grammar but only whether it improves *Conventional Commits* or not. - Expected meaning: "I updated the `doc`... impacting `build(ModuleA)` > doc::build(ModuleA): Clarify which CFLAGS are required or optional [...] - Expected meaning: "I `doc`umented the `build` relative to scope `ModuleA` > doc(build:ModuleA): Clarify which CFLAGS are required or optional [...] - Expected meaning: "I updated the `build` relative to scope `doc` in `ModuleA` > build(doc:ModuleA): Clarify which CFLAGS are required or optional [...] ## Use cases and reach What do you think about adding the possibility to specify that? This can cover a lot more such as: - `refactor` in order to `fix` - `fix` a `test` - `refactor` the `ci` pipelines - `perf` improvement in scope `ModuleC` of `repoB` in a monorepo - `revert` a `feat` - etc. Of course, if you `refactor` the `ci` pipelines, you **refactored** and the remainder could go in the description, the body or the footer. The sub-typing does not resolve something impossible but, in my opinion, extends and add clarity to the scope. Sub-typing also allows more fine grained scopes for monorepos by allowing some kind of scope hierarchy, In both of my commit messages compliant with *Conventional Commits 1.0.0*, someone has to read the description to understand the real scope of my commit. I believe this illustrates a small gap in the scope syntax. Finally, sub-typing naturally allows meta-types such as: - `revert` type whose sub-type would be the reverted type - `wip` type whose sub-type would be the final type (`wip:fix`, `wip:feat`, etc.) ## Drawbacks ### What should be the maximal sub-type depth ? Maybe I updated the `style` of the `doc` of the `build` in the scope of `ModuleA`... and I could go on if I wanted to be creative. I think this would follow the semantics of the [angular guidlines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) but is clearly a worse choice than a type overlap. ### Meaningless sub-types Although this could be suppressed by simply applying common sense, sub-typing introduces the possibility to `revert` a `fix` or `style` a `refactor`. I think this is not a real concern but I mention it to maybe open the discussion to more concerning issues. # Related issues - [mono-repo support](https://github.com/conventional-commits/conventionalcommits.org/issues/269) - [feature request: supporting multiple scopes](https://github.com/conventional-commits/conventionalcommits.org/issues/302) - [What about the revert type?](https://github.com/conventional-commits/conventionalcommits.org/issues/88) - [Fixed type lengths [suggestion]](https://github.com/conventional-commits/conventionalcommits.org/issues/246) edit: typos

GiteaMirror commented

2026-02-17 11:48:55 -06:00

@jalaziz commented on GitHub (Jan 7, 2022):

I would love to see subtyping and/or support for multiple scopes. We have a monorepo use case and the current standard is too limiting to impart helpful context in some situations, unfortunately.

@jalaziz commented on GitHub (Jan 7, 2022): I would love to see subtyping and/or support for multiple scopes. We have a monorepo use case and the current standard is too limiting to impart helpful context in some situations, unfortunately.

GiteaMirror commented

2026-02-17 11:48:56 -06:00

@fterrani commented on GitHub (Jul 17, 2024):

@Zorvalt I encountered a similar issue when thinking about the hypothetical (or not?) wip type. Here are two other syntax ideas: https://github.com/conventional-commits/conventionalcommits.org/issues/38#issuecomment-2223084138

@fterrani commented on GitHub (Jul 17, 2024): @Zorvalt I encountered a similar issue when thinking about the hypothetical (or not?) `wip` type. Here are two other syntax ideas: https://github.com/conventional-commits/conventionalcommits.org/issues/38#issuecomment-2223084138

GiteaMirror referenced this issue

2026-02-17 11:58:29 -06:00

[PR #136] [CLOSED] Add 'resolves:' type for message body #310

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#135