changeset add --patch -m 'Fix the export types' fails before it does anything:
CACError: option `--patch <pkg>` value is missing
I'd like a bare --patch to mean "patch everything you detected". The detection already runs, it just gets dropped on the floor.
The detection is already there
add() works out changedPackagesNames on every run, before anything branches, and passes it into createChangeset. The first branch of that function is:
if (optionsFromCli?.major || optionsFromCli?.minor || optionsFromCli?.patch) {
// builds releases from the CLI lists only, changedPackages is never read
}So the right answer is sitting in scope, unused. The interactive path takes that same value and shows it as the changed packages group.
Why I care
The non-interactive path is the agent path, and an agent has no TTY. That leaves two options and I'm not keen on either.
Pass --patch <pkgs> and work the list out yourself. That's the step that goes wrong. On one of our PRs the hand-built list named 2 packages where the real answer was 5.
Or drop the bump flags to get the detection, which ends in a groupMultiselect with required: true and nothing preselected. There's no CI or non-TTY fallback in add, so with piped input it writes nothing and exits on the unsettled prompt.
A human never hits this. changeset add groups the changed packages and selectableGroups: true takes the lot in one keystroke. It's only the scripted path that's stuck, which feels backwards.
What I'm suggesting
Make the value optional and fall back to the detected list.
changeset add --patch -m 'Fix the export types' # patch everything detected
changeset add --patch pkg-a,pkg-b -m '...' # unchanged
That's --patch [pkg] in the option declaration, and using changedPackages in createChangeset when a bump flag carries no value. --since would compose with it too, which it can't today.
Happy to open a PR if that shape looks right. I'd be interested to hear if there's a reason it works the way it does, I might be missing something.
On @changesets/cli 3.0.1, cac 7.0.0, Node 24.20.0, pnpm workspace.
Follow-up to #2152 and #1121, which added the flags but kept the package list mandatory.
changeset add --patch -m 'Fix the export types'fails before it does anything:I'd like a bare
--patchto mean "patch everything you detected". The detection already runs, it just gets dropped on the floor.The detection is already there
add()works outchangedPackagesNameson every run, before anything branches, and passes it intocreateChangeset. The first branch of that function is:So the right answer is sitting in scope, unused. The interactive path takes that same value and shows it as the
changed packagesgroup.Why I care
The non-interactive path is the agent path, and an agent has no TTY. That leaves two options and I'm not keen on either.
Pass
--patch <pkgs>and work the list out yourself. That's the step that goes wrong. On one of our PRs the hand-built list named 2 packages where the real answer was 5.Or drop the bump flags to get the detection, which ends in a
groupMultiselectwithrequired: trueand nothing preselected. There's no CI or non-TTY fallback inadd, so with piped input it writes nothing and exits on the unsettled prompt.A human never hits this.
changeset addgroups the changed packages andselectableGroups: truetakes the lot in one keystroke. It's only the scripted path that's stuck, which feels backwards.What I'm suggesting
Make the value optional and fall back to the detected list.
That's
--patch [pkg]in the option declaration, and usingchangedPackagesincreateChangesetwhen a bump flag carries no value.--sincewould compose with it too, which it can't today.Happy to open a PR if that shape looks right. I'd be interested to hear if there's a reason it works the way it does, I might be missing something.
On
@changesets/cli3.0.1, cac 7.0.0, Node 24.20.0, pnpm workspace.Follow-up to #2152 and #1121, which added the flags but kept the package list mandatory.