mono-repo support

[ghermeto]

@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.

[djgilcrease]

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

[vjpr]

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

[wesleytodd]

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?

[ghermeto]

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.

[wesleytodd]

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?

[ghermeto]

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...

[nedbat]

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

[jalaziz]

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.

[damianopetrungaro]

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?