Repository navigation
[create-release-branch] Revise CLI to be interactive #56
Description
Currently, create-release-branch will generate a file that you are expected to edit before re-running the tool. If you have EDITOR set or if code exists, then it will open this file for you. However, most people are using VSCode, and VSCode doesn't create a code executable by default. Therefore it would create a more friendly and inclusive experience to replace this workflow with one that's more interactive. It would present a set of changed packages and let you choose major, minor, or patch for each of the packages.
The tool could print something like this:
The
create-release-branchtool has reviewed the changes since the previous release (39.0.0). Based on this analysis, there may be 3 packages that need releasing.You now need to determine how the versions for these packages should be bumped.
To do this, you'll want to pull up the history for this repo and go through the commits that have occurred since 39.0.0 was released. For each commit, review the changes along with its summary. Take note of which files were changed and which package those files belong to. (Keep in mind that each directory in
packages/is one package, and each package may have multiple files inside.)In the end, for each package changed, you want to know:
- Were there any breaking changes? For instance, a public export or a method in a public class was renamed or removed entirely. If so you can stop here: we want to bump the
majorpart of the package.- If no breaking changes, were there any additions to the API made? For instance, a new export was added or a new method was added to a public class. If so you can stop here: we want to bump the
minorpart of the package.- Were there any other changes made that aren't breaking changes or additions to the API? For instance, part of the logic in a file was fixed to remove a bug. If so, we want to bump the
patchpart of the package.
Then it would list each package and offer the user a way to select major, minor, or patch for each package — something like:
(Use arrow keys ← → ↑ ↓ to select, and Enter ↩︎ to confirm.)
+----------------------------------+-----------------------------------+
+ Name | Bump strategy |
+----------------------------------+-----------------------------------+
+ @metamask/assets-controller | ◉ major ○ minor ○ patch ○ skip |
+----------------------------------+-----------------------------------+
+ @metamask/network-controller | ○ major ◉ minor ○ patch ○ skip |
+----------------------------------+-----------------------------------+
+ @metamask/transaction-controller | ○ major ○ minor ◉ patch ○ skip |
+----------------------------------+-----------------------------------+
When you pressed Enter it would spit out a confirmation screen, something like:
Based on your selection, the tool will bump the versions of the following packages and update their changelogs to match.
∙ @metamask/assets-controller (2.0.0 → 3.0.0)
∙ @metamask/network-controller (2.0.0 → 2.1.0)
∙ @metamask/transaction-controller (2.0.0 → 2.0.1)
Do you want to proceed? (y/n)
Activity
mcmire commentedon Jan 30, 2023
The new beta CLI for the Render PAAS looks very cool. We might consider borrowing some ideas from this tool.
I'm sure there are other tools we could consider for inspiration as well.
mcmire commentedon Feb 3, 2023
Astro also has a very nifty CLI: https://twitter.com/n_moore/status/1621524815550074880
[-]Revise workflow to be interactive[/-][+]Revise CLI to be interactive[/+]mcmire commentedon Jul 1, 2025
I know that we will most likely retire the CLI, but just in case we don't, the
bubbletealibrary seems like it could be useful.[-]Revise CLI to be interactive[/-][+][create-release-branch] Revise CLI to be interactive[/+]