Affected Packages
@changesets/cli, perhaps a new package would be more appropriate for this functionality
Problem
Our organization has been versioning packages with lerna + conventional commits for a while now, but we are looking at moving towards changesets, mainly because the .changeset/config.json is just awesome. I love how you can make explicit associations between different packages - this is exactly what the conventional commits workflow has been missing imo.
Our developers have become accustomed to the conventional commit workflow and I think that providing an integration could go a long way in terms of facilitating adoption for other organizations as well.
Proposed solution
I am hoping something similar to the following would be possible.
Given some number of conventional commits since master n, and some arbitrary number of packages in a mono-repo, running changeset version should:
-
Visit each of the n commits and determine the proper version bump based on the commit message and affected package. For example, if you have a commit that affects package A: feat: Add some feature to package A, the associated version bump should be translated to a minor bump of package A. Similarly if you have a commit to package B: fix: Fix something, the associated version bump should be translated to a patch bump of package B.
-
Once the version bumps from conventional commits are determined, pre-populate the changeset version prompts with the respective bumps. In the example above with package A, when the prompt asks Which packages should have a minor bump?, package A should already be pre-selected. I would also see this pre-populating the prompt. Please enter a summary for this change (this will be in the changelogs).
I would also hope for a flag that would allow us to auto-generate the changesets from conventional commits (without any additional prompting). That being said, I can see how this specifically may be at odds with the generally recommended changeset workflow.
I am new to changesets, so I am currently unfamiliar with how it is set up, or how much of a shift this would be. Hoping I can get an idea of whether this something that others would find valuable, and/or what changes might be necessary to facilitate this. I am happy to help out however possible with this effort. Alternatively, if there is any sort of plugin-based API for third-party integrations, that may be more appropriate for this use case, but I am unaware of such an API.
Cheers!
Affected Packages
@changesets/cli, perhaps a new package would be more appropriate for this functionalityProblem
Our organization has been versioning packages with lerna + conventional commits for a while now, but we are looking at moving towards changesets, mainly because the
.changeset/config.jsonis just awesome. I love how you can make explicit associations between different packages - this is exactly what the conventional commits workflow has been missing imo.Our developers have become accustomed to the conventional commit workflow and I think that providing an integration could go a long way in terms of facilitating adoption for other organizations as well.
Proposed solution
I am hoping something similar to the following would be possible.
Given some number of conventional commits since master
n, and some arbitrary number of packages in a mono-repo, runningchangeset versionshould:Visit each of the
ncommits and determine the proper version bump based on the commit message and affected package. For example, if you have a commit that affects package A:feat: Add some feature to package A, the associated version bump should be translated to a minor bump of package A. Similarly if you have a commit to package B:fix: Fix something, the associated version bump should be translated to a patch bump of package B.Once the version bumps from conventional commits are determined, pre-populate the
changeset versionprompts with the respective bumps. In the example above with package A, when the prompt asksWhich packages should have a minor bump?, package A should already be pre-selected. I would also see this pre-populating the prompt.Please enter a summary for this change (this will be in the changelogs).I would also hope for a flag that would allow us to auto-generate the changesets from conventional commits (without any additional prompting). That being said, I can see how this specifically may be at odds with the generally recommended changeset workflow.
I am new to changesets, so I am currently unfamiliar with how it is set up, or how much of a shift this would be. Hoping I can get an idea of whether this something that others would find valuable, and/or what changes might be necessary to facilitate this. I am happy to help out however possible with this effort. Alternatively, if there is any sort of plugin-based API for third-party integrations, that may be more appropriate for this use case, but I am unaware of such an API.
Cheers!