[code-infra] Setup internal package publishing#5142
Conversation
brijeshb42
commented
Jun 30, 2026
brijeshb42
commented
- I have followed (at least) the PR section of the contributing guide.
brijeshb42
added
the
scope: code-infra
commit: |
Bundle size
PerformanceTotal duration: 1,202.91 ms -100.08 ms(-7.7%) | Renders: 78 (+0)
13 tests within noise — details Metric alarms
Check out the code infra dashboard for more information about this PR. |
✅ Deploy Preview for base-ui ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
f025df1 to
564a79c
Compare
| "release:publish": "code-infra publish --github-release", | ||
| "release:publish:dry-run": "code-infra publish --github-release --dry-run ", | ||
| "release:publish:dry-run": "code-infra publish --github-release --dry-run", | ||
| "release:publish:internal": "code-infra publish -- --internal-packages", |
There was a problem hiding this comment.
🤔 I still don't fully understand what we get out of this. Why is it not just the responsibility of the releaser to only bump the version of what needs to be published? A special mode for internal packages is not doing anything special, right?
I mean the points of failure are:
- the user versions the correct packages
- the user runs the correct command
If we put this in a matrix for a partial release
two commands available
| user runs: | partial command | accidental full command |
|---|---|---|
| versions correct | publish correct packages | publish correct packages |
| versions incorrect | cli errors | cli publishes wrong packages |
vs.
one command available
| user runs: | full command |
|---|---|
| versions correct | publish correct packages |
| versions incorrect | cli publishes wrong packages |
The failure mode remains the same, the user needs to version correctly.
There was a problem hiding this comment.
A special mode for internal packages is not doing anything special
Right. Nothing special.
This is an extra guardrail from code-infra side to avoid accidentally publishing @base-ui/react since this package has its monthly release cadence associated with the whole repo.
The new job makes it explicit what the internal packages are and only those will get published regardless of whether react's version was bumped or not. This can be updated over time to whitelist other packages as relevant.
There was a problem hiding this comment.
I kind of feel like the safeguard is in the wrong place. Aren't we only adding it because the version bump is so crude and not adapted to our use-case that errors are easy to happen? Maybe it's the version CLI that needs the safeguard, not the publish one? It's like we're adding complexity to an already complex flow, just to prevent errors from a tool that is not properly adapted to our use-case.
Does the dry run on the CLI print what would be published? Maybe instead we could always do a dry-run, print the result, ask for confirmation, if yes, do for real? This doesn't add any new modes and contains the complexity to a local check only. + improves the UX of the tool.
There was a problem hiding this comment.
I don't think people are going to be invoking lerna to bump the version for utils. They'll just update package.json manually. IMO, it doesn't even make sense to be here in this repo with only two packages. It does make sense for core or x where there are more than 10 packages.
There was a problem hiding this comment.
Ok, and doing the dry-run, then print like
Attention: You are about to execute the followong actions
- publish packages:
- @base-ui/utils v1.2.3.
- ...
- publish a GH release
press [enter] to proceed, press [?] to review the changelog, press [esc] to cancel
? Would that be hard to do? I mean, if you then still accidentally publish, then it really is your own fault.
There was a problem hiding this comment.
But nothing is stopping anyone from triggering the GH workflow directly where we can't have this.
There was a problem hiding this comment.
🤔 We should be able to control that using workflow execution protections (maybe, just learnt about this)
Actor rules control who can trigger workflows, including individual users, repository roles such as Read, Maintain, and Admin, GitHub Apps, Copilot, and Dependabot.
I guess we can restrict it to our GitHub App.
There was a problem hiding this comment.
This would work. But how would the cli trigger the action ? It would have to trigger on behalf of the app but then anyone running the cli would be able to trigger it. I am probably missing something.
There was a problem hiding this comment.
Well, the app runs it on behalf of the user no? Isn't that how our auth works? app requests a token scoped to workflow_dispatch, and the user signs in to create that token, only if the user has the rights to workflow_dispatch.
Not sure if workflow execution protection means the app as the one executing the API, or the app as an owner of credentials.
github-actions
Bot
added
the
PR: out-of-date
2 participants
