-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to support monorepo where scopes are different packages? #210
Comments
Thanks for the report! Could it be because your 1.0.0 tag is called [email protected], and maybe ctv isn't picking it up as relevant? If this is this case, you'd see some of the same commits in the changelog again (including the breaking change). Either way, what, exactly, is in your changelog? Also - does the bug reproduce with your condensed versionrc.js? Lastly, I think your |
Hey @TimothyJones appreciate the response. That is correct, it does use the tagging system of using the package name as the tag prefix. This matches the scope in the commits and also the approach that ctv suggests: https://github.com/absolute-version/commit-and-tag-version?tab=readme-ov-file#prefix-tags To answer your question about the CHANGELOG, here is the full log it generates for the v2.0.0 release it tries to create (apologies about the length):
As you can see no breaking changes are present (BREAKING CHANGE, or !). Does ctv provide a way to influence how the release is versioned? i.e. is there a function similar to |
I ran the command with verbose set to true and got this additional context, although not super helpful in understanding why the package was majorly bumped:
|
@TimothyJones I think I figured out what's going on - the commits that are used to produce the CHANGELOG are different to the commits that are used to determine the version bump. When I run
And that it's looking at commits from other scopes (packages). Is there way to filter commits? I have tried using |
Yeah, I think this is the reason - using the scope to denote packages isn't what conventional commits expects. This project is just a thin wrapper around conventional changelog, so if it were possible there we could make it possible here. It looks like potentially ignore could be (ab)used to do what you want, although it looks like it's not exposed. Either way, I think this is a feature request, rather than a bug. |
Describe the bug
I am using
commit-and-tag-version
in my project Terra Draw. The project is a monorepo, and has packages in thepackages
folder. I filter the CHANGELOG based on scopes that are the package names (terra-draw
,terra-draw-leaflet-adapter
etc). All seemed to be working okay, until I went to release a new version ofterra-draw
and I am being bumped from version1.0.0
to what I would assume would be1.1.0
but it is creating a change log for2.0.0
. In the CHANGELOG there are no breaking changes, and 2feat
changes (hence expecting a minor bump rather than major). I am running it like so for the dry run:The (condensed) version of the
.versionrc.cjs
file looks like this:Current behavior
The packages attempts to bump to version 2.0.0 even though there are no breaking changes
Expected behavior
It bumps to version 1.1.0 as there are no breaking changes, and only
feat
entriesEnvironment
commit-and-tag-version
version(s): 12.5.0Possible Solution
Is there some possibility because this is a monorepo it is picking up previous historical commits somehow that don't relate to the package? Hard to say
Additional context
Here is a GitHub Action with the dry run and created CHANGELOG: https://github.com/JamesLMilner/terra-draw/actions/runs/13041702361/job/36384792942
The text was updated successfully, but these errors were encountered: