We will have to also update this in changesets/action:
https://github.com/changesets/action/blob/595655c3eae7136ff5ba18200406898904362926/src/run.ts#L95

changesets/action should be built on top of @changesets/release-utils - but this wasn't yet unified.

Got it, will check it out.

As an aside, could be interesting to explore moving the source code for actions into the monorepo as a package. We've had some success with this with action collections in monorepos.

The "publish" command, instead of being NPM-based, becomes git-based: you build the action, bundle dist up into a single file (with @vercel/ncc or your favorite equivalent), and then your calculated version (e.g. 4.1.0) becomes the branch name... you push the files directly into branch v4.1.0 in the target repo, changesets/action.

(To follow GH conventions, you usually also have branches for major versions, so you follow it up by chopping off and fast-forwarding, e.g. git checkout v4 && git reset --hard v4.1.0 && git push -f in the target repo.)

This also brings up the whole question of "well... what if I wanted changesets to manage publishing all my actions, using this alternate publishing scheme?". That's a question we never really dug into Rush but I've always thought it would be cool if it was as simple as:

[
  {
    "packageName": "@example/core",
    "shouldPublish": true,
    "publishMethod": "pnpm"
  },
  {
    "packageName": "@example/custom-action",
    "shouldPublish": true,
    "publishMethod": "github-action",
    "targetRepo": "example-company/custom-action"
  }
]

And then you'd just "publish all" and everything is done for you.

Ye, it would be kinda neat if the changesets/action repo could just become a publish target.

If I'm not mistaken - this is a breaking change for @changesets/apply-release-plan. This is fine - we just have to create a major changeset for it

Is it major? I might misunderstand the ramifications but I think apply-release-plan's external behavior for all existing monorepo implementations doesn't change (it's just a dependency bump + corresponding implementation tweak).

The problem is in the API surface - not the behavior. It now accepts an argument of a different shape

👋

Hm, quite interesting that you are hitting timeouts here - somewhat similarly to what happened in manypkg repo. There is likely some overhead in spawn here but I never had problems with this - even on the older machine.

🤔 I wonder why... on the other repo, upgrading that ts wrapper tool made the timeout issues vanish.

But in this case, it's only this specific test that consistently goes over 5 seconds for me, and it's the test that calls git 50+ times so it made sense to me that it was a bit slower.

Out of curiosity - could you check how long those spawn('git', ...) calls take on your machine? It would be interesting to learn more about this particular bottleneck. This is, of course, just a sideways exploration - not quite related to this PR.