mono-repo support #100

New Issue

GiteaMirror · 2026-02-17T11:45:42-06:00

GiteaMirror commented

2026-02-17 11:45:42 -06:00

Originally created by @ghermeto on GitHub (May 21, 2020).

@bcoe @wesleytodd I would like to restart this discussion in a more holistic way.

As I have been working more and more with mono repos, I feel the representation is lacking. My concern is less about CHANGELOGS and more when visually inspecting a commit log, I can't determine which package change. I have to look at the commit path or the body. As a change was made to add ! to represent breaking changes, I believe we can make a change to represent mono-repos.

It would make easy building automation around mono-repos for polyglot adoption. As much as I like lerna, it is just one tool in the toolbox for mono-repos and is very javascript/node.js centric. You can have mono-repos what use workspaces, mono-repos with clients in multiple languages or no js involved at all.

I wanted restart this conversation without bias towards any solution, so I won't propose a solution. I want align on the issue, before we try to solve it.

Originally created by @ghermeto on GitHub (May 21, 2020). @bcoe @wesleytodd I would like to [restart this discussion](https://github.com/conventional-commits/conventionalcommits.org/issues/118) in a more holistic way. As I have been working more and more with mono repos, I feel the representation is lacking. My concern is less about `CHANGELOGS` and more when visually inspecting a commit log, I can't determine which package change. I have to look at the commit path or the body. As a change was made to add `!` to represent breaking changes, I believe we can make a change to represent mono-repos. It would make easy building automation around mono-repos for polyglot adoption. As much as I like `lerna`, it is just one tool in the toolbox for mono-repos and is very javascript/node.js centric. You can have mono-repos what use workspaces, mono-repos with clients in multiple languages or no js involved at all. I wanted restart this conversation without bias towards any solution, so I won't propose a solution. I want align on the issue, before we try to solve it.

GiteaMirror commented

2026-02-17 11:45:44 -06:00

@djgilcrease commented on GitHub (May 28, 2020):

I just use the scope section to denote which project the change applies to in a mono repo

@djgilcrease commented on GitHub (May 28, 2020): I just use the scope section to denote which project the change applies to in a mono repo

GiteaMirror commented

2026-02-17 11:45:45 -06:00

@vjpr commented on GitHub (Jun 7, 2020):

Firstly, a big advantage of monorepos is atomic commits (having one commit update multiple packages). For this reason, placing the affected packages inside the first commit line is untenable.

In a company monorepo I have multiple projects each with multiple components. For example, for project-a I might have a web app and a react-native mobile app.

I mirror open-source code publicly using git subtree so I also need a way to separate open source commits from internal commits.

I use something like:

[pub/bar-library/component-a] Add this thing
[org/foo-project/web] Add that thing
[org/foo-project/service-bar] Add these things

@vjpr commented on GitHub (Jun 7, 2020): Firstly, a big advantage of monorepos is atomic commits (having one commit update multiple packages). For this reason, placing the affected packages inside the first commit line is untenable. In a company monorepo I have multiple projects each with multiple components. For example, for `project-a` I might have a web app and a react-native mobile app. I mirror open-source code publicly using `git subtree` so I also need a way to separate open source commits from internal commits. I use something like: ``` [pub/bar-library/component-a] Add this thing [org/foo-project/web] Add that thing [org/foo-project/service-bar] Add these things ```

GiteaMirror commented

2026-02-17 11:45:46 -06:00

@wesleytodd commented on GitHub (Sep 30, 2020):

I think this would be an interesting use for footers (maybe even some specific tokens like we have in the type). I know this means that the typical one-line git log will not have it, but is that an acceptable compromise @ghermeto, so we can support something like what @vjpr mentions?

The problem is, there is just no way to make a legible and valuable header line if we have multiple paths or sub-components listed. IMO, something like this could work:

fix: converted from new Buffer to Buffer.from

Path: pub/bar-library/component-a
Path: org/foo-project/web
Path: org/foo-project/service-bar

Where as something like these get unmanageable very quickly:

fix(pub/bar-library/component-a,org/foo-project/web, org/foo-project/service-bar): converted from new Buffer to Buffer.from

fix: converted from new Buffer to Buffer.from in pub/bar-library/component-a org/foo-project/web, org/foo-project/service-bar

Automation could help generate these footers and parsers would know the Path footer token points to a path in the repo which was effected by the change. Maybe adding Path and Component as standard footer tokens where path points to a sub directory and component is a named sub component?

@wesleytodd commented on GitHub (Sep 30, 2020): I think this would be an interesting use for footers (maybe even some specific tokens like we have in the type). I know this means that the typical one-line git log will not have it, but is that an acceptable compromise @ghermeto, so we can support something like what @vjpr mentions? The problem is, there is just no way to make a legible and valuable header line if we have multiple paths or sub-components listed. IMO, something like this could work: ``` fix: converted from new Buffer to Buffer.from Path: pub/bar-library/component-a Path: org/foo-project/web Path: org/foo-project/service-bar ``` Where as something like these get unmanageable very quickly: ``` fix(pub/bar-library/component-a,org/foo-project/web, org/foo-project/service-bar): converted from new Buffer to Buffer.from ``` ``` fix: converted from new Buffer to Buffer.from in pub/bar-library/component-a org/foo-project/web, org/foo-project/service-bar ``` Automation could help generate these footers and parsers would know the `Path` footer token points to a path in the repo which was effected by the change. Maybe adding `Path` and `Component` as standard footer tokens where path points to a sub directory and component is a named sub component?

GiteaMirror commented

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

@ghermeto commented on GitHub (Sep 30, 2020):

As long as it is part of the standard, using a footer is a viable option, although I have to say Component is a much better, although verbose, alternative to Path (which is very loaded). Maybe we should also consider other tokens' names, like Module or Package.

@ghermeto commented on GitHub (Sep 30, 2020): As long as it is part of the standard, using a footer is a viable option, although I have to say `Component` is a much better, although verbose, alternative to `Path` (which is very loaded). Maybe we should also consider other tokens' names, like `Module` or `Package`.

GiteaMirror commented

2026-02-17 11:45:49 -06:00

@wesleytodd commented on GitHub (Oct 5, 2020):

Yeah, Component is generic and "better" in some cases, but I think that it provides less guarantees about how to find the component in the repo. Path is very clear on it's intent, and in many cases Module/Package/Component rely on some tooling to translate a name to location on disk. For a JS style monorepo "workspace", this relies on the semantics built into the tooling (yarn/lerna/npm). I am sure there would be similar tooling in non-JS ecosystems.

Would we want to include these even if we cannot provide meaningful semantics to them?

@wesleytodd commented on GitHub (Oct 5, 2020): Yeah, `Component` is generic and "better" in some cases, but I think that it provides less guarantees about how to find the component in the repo. `Path` is very clear on it's intent, and in many cases `Module`/`Package`/`Component` rely on some tooling to translate a name to location on disk. For a JS style monorepo "workspace", this relies on the semantics built into the tooling (`yarn`/`lerna`/`npm`). I am sure there would be similar tooling in non-JS ecosystems. Would we want to include these even if we cannot provide meaningful semantics to them?

GiteaMirror commented

2026-02-17 11:45:50 -06:00

@ghermeto commented on GitHub (Oct 6, 2020):

I'm sensitive to automation concerns and at the same time, I would like to provide a better level of abstraction. I don't see myself, as a user, ever writing a commit message like this:

fix: converted from new Buffer to Buffer.from

Path: package/lib-foo
Path: package/lib-bar
Path: package/lib-baz

as the Path can be inferred from the actual commit. We need to first be sensitive to the users that will have to write these commit messages. As soon as we make it harder, people will stop using it. I would prefer something shorter like:

fix: converted from new Buffer to Buffer.from

Packages: lib-foo, lib-bar, lib-baz

Using "Packages" seems fitting because we have them in Javascript, Java, Python, Rust, UML, etc...

@ghermeto commented on GitHub (Oct 6, 2020): I'm sensitive to automation concerns and at the same time, I would like to provide a better level of abstraction. I don't see myself, as a user, ever writing a commit message like this: ``` fix: converted from new Buffer to Buffer.from Path: package/lib-foo Path: package/lib-bar Path: package/lib-baz ``` as the **Path** can be inferred from the actual commit. We need to first be sensitive to the users that will have to write these commit messages. As soon as we make it harder, people will stop using it. I would prefer something shorter like: ``` fix: converted from new Buffer to Buffer.from Packages: lib-foo, lib-bar, lib-baz ``` Using "**Packages**" seems fitting because we have them in Javascript, Java, Python, Rust, [UML](https://en.wikipedia.org/wiki/Package_diagram), etc...

GiteaMirror commented

2026-02-17 11:45:51 -06:00

@nedbat commented on GitHub (Feb 25, 2021):

Can't the package also be inferred from the file paths?

@nedbat commented on GitHub (Feb 25, 2021): Can't the package also be inferred from the file paths?

GiteaMirror commented

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

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

Been working with monorepos for a while and agree that the current standard is not sufficient.

The issue is mainly that the current standard only allows room for a single "scope". If multiple scopes were allowed, then I think that could be a decent middle ground.

Can't the package also be inferred from the file paths?

Yes, but that's not useful when looking at a list of commits (which is valuable for release managers, for example).

Firstly, a big advantage of monorepos is atomic commits (having one commit update multiple packages). For this reason, placing the affected packages inside the first commit line is untenable.

But quite often a commit will only affect one package, in which case including the package name is useful. If it's a feature/fix across multiple packages, then we normally label with only the feature name.

@jalaziz commented on GitHub (Jan 7, 2022): Been working with monorepos for a while and agree that the current standard is not sufficient. The issue is mainly that the current standard only allows room for a single "scope". If multiple scopes were allowed, then I think that could be a decent middle ground. > Can't the package also be inferred from the file paths? Yes, but that's not useful when looking at a list of commits (which is valuable for release managers, for example). > Firstly, a big advantage of monorepos is atomic commits (having one commit update multiple packages). For this reason, placing the affected packages inside the first commit line is untenable. But quite often a commit will only affect one package, in which case including the package name is useful. If it's a feature/fix across multiple packages, then we normally label with only the feature name.

GiteaMirror commented

2026-02-17 11:45:54 -06:00

@damianopetrungaro commented on GitHub (Jan 19, 2022):

We can create a PR to support multiple scopes in a single commit and see if we wanna go further with it then :D

I do remember I've already seen one but I can't find it back.

Anyone volunteer?

@damianopetrungaro commented on GitHub (Jan 19, 2022): We can create a PR to support multiple scopes in a single commit and see if we wanna go further with it then :D I do remember I've already seen one but I can't find it back. Anyone volunteer?

GiteaMirror referenced this issue

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

[PR #100] [MERGED] docs: Main title and small general improvements #286

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#100