melos
melos copied to clipboard
chores are not considered by melos version
Hey
I'm in a situation where I upgraded a dependency across my packages (graphql 5.0.0-beta.2 -> graphql 5.0.0
), and marked it a chore. The upgrade is the sole commit on top of the previous version.
It appears that melos version
does not consider the chore versionable. Shouldn't it be?

And if not, maybe logging something like "X commits were not versionable", or something to that effect? I would have found that helpful.
Based on the conventional commits spec chore commits alone don't trigger a version since it's usually used for non-production code changes, e.g. adding a build script. They do however appear in change logs if there's other commits that did trigger a version bump.
I'd be open to have logging as part of melos version
that shows all the commits being picked up, chore and non-chore. Option B would be add a config to allow chore to be versionable
Based on the conventional commits spec chore commits alone don't trigger a version since it's usually used for non-production code changes, e.g. adding a build script. They do however appear in change logs if there's other commits that did trigger a version bump.
Ahhh, got it.
I'd be open to have logging as part of melos version that shows all the commits being picked up, chore and non-chore. Option B would be add a config to allow chore to be versionable
I think that option B might make sense. It's nice to be prescriptive, but escape hatches are good too.
I think my ideal would be to understand what was happening through command output, and be given a clear option on how to force a version if I wish to.
Ultimately I rewrote history. Not a big deal, but I also had to figure it out first.
Relevant TODO (since I don't think this should exist in the conventional commit package): https://github.com/invertase/melos/blob/master/packages/conventional_commit/lib/conventional_commit.dart#L214-L228
I also envisioned that you could configure the specific types supported in the conventional commits package and which ones are versionable (outside of conventional commits package).
My 2 cents :P
Relevant TODO (since I don't think this should exist in the conventional commit package): https://github.com/invertase/melos/blob/master/packages/conventional_commit/lib/conventional_commit.dart#L214-L228
Gotcha
I also envisioned that you could configure the specific types supported in the conventional commits package and which ones are versionable (outside of conventional commits package).
Agreed.