pr-status already computes the full release plan (via @changesets/get-release-plan) to build its comment, then only exposes comment-body. Could it also surface that same data as structured outputs?
These would be suuuper useful:
max-bump: the highest of major/minor/patch across the released packages, or nonereleases: JSON array of { name, type, oldVersion, newVersion } per package
The current code for this action already carries all of this (per-package type plus old and new versions), so nothing new needs computing.
I currently label a PR patch/minor/major from the bump by manually parsing the files in the .changesets folder. The code for that would become much simpler if I could get these outputs directly. And this action already handles the pull_request_target fork-safety, so I wouldn't have to worry about that.
I already have a draft locally for this, but I wanted to check if this is something you'd be open to before I submit it. If so, I can clean it up and submit a PR. Pls lmk!
pr-statusalready computes the full release plan (via@changesets/get-release-plan) to build its comment, then only exposescomment-body. Could it also surface that same data as structured outputs?These would be suuuper useful:
max-bump: the highest ofmajor/minor/patchacross the released packages, ornonereleases: JSON array of{ name, type, oldVersion, newVersion }per packageThe current code for this action already carries all of this (per-package type plus old and new versions), so nothing new needs computing.
I currently label a PR
patch/minor/majorfrom the bump by manually parsing the files in the.changesetsfolder. The code for that would become much simpler if I could get these outputs directly. And this action already handles thepull_request_targetfork-safety, so I wouldn't have to worry about that.I already have a draft locally for this, but I wanted to check if this is something you'd be open to before I submit it. If so, I can clean it up and submit a PR. Pls lmk!