Repository navigation
feat: support workspace-managed native publishing - #88
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8b823d0d2d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
matthewkeil
moved this from In Progress
to Awaiting Author
in Lodestar Team Coordination
nflaig
left a comment
nflaig
left a comment
There was a problem hiding this comment.
LGTM. Checked the Lerna flow against lerna-lite: the manifest is reloaded after prepack and read from disk at publish, so optionalDependencies reach the registry metadata.
Non-blocking: a quick re-run during registry lag can still hit E403 "cannot publish over the previously published versions"; treating that as skipped (like lerna-lite does) would cover it.
github-project-automation
Bot
moved this from Awaiting Author
to Done
in Lodestar Team Coordination
🤖 I have created a release *beep* *boop* --- ## [4.3.0](zapi-v4.2.0...zapi-v4.3.0) (2026-10-31) ### Features * support workspace-managed native publishing ([#88](#88)) ([78ba34f](78ba34f)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
publish-dev has failed on every unstable push since #10513. zapi published `@lodestar/native` seconds before `lerna publish from-package` checked the registry. npm still reported the version as unpublished, so Lerna ran the wrapper's `prepublishOnly` guard and the job failed. Only the 7 native packages reached npm, and the Docker publish was skipped. This bumps zapi to 4.3.0 (ChainSafe/zapi#88) and splits publishing by package type: - zapi builds and publishes only the platform packages, with `--skip-existing` so a failed release can be re-run from any point. - Lerna publishes the wrapper with the other packages. Its `prepack` script (`zapi prepublish --main-only`) pins the platform packages as `optionalDependencies`, replacing the throwing guard. Verified locally with fake artifacts: - `zapi publish --platforms-only --skip-existing --dry-run` would publish all 6 platforms for an unpublished version and skips all 6 for `1.51.0-dev.122e5d5f21`. - `lerna publish from-package --dry-run` found only `@lodestar/native@1.50.1` unpublished, ran `prepack`, and the packed tarball lists all 6 platform `optionalDependencies`.
A workspace publisher such as Lerna must own the wrapper's version and publication, while zapi handles the native platform packages. Currently both tools can publish the wrapper, and preparing its optional dependencies before Lerna starts dirties the tracked manifest.
This separates the existing commands by package type:
prepublish --platforms-onlyprepares platform packages without modifying the wrapper manifest.prepublish --main-onlyupdates native optional dependencies while preserving unrelated dependencies and removing retired native targets. Running it inprepackgenerates the wrapper metadata after Lerna's clean-tree check.publish --platforms-onlypublishes platforms and leaves the wrapper to the workspace publisher.publish --skip-existingskips existing versions in the destination registry. It respectspublishConfig, scoped registries, and explicit npm CLI overrides; failures other than E404 abort. Existing versions and dist-tags remain untouched.Preparation copies artifacts so it can be repeated and fails if an artifact is missing. Generated platform packages inherit
publishConfig. Publishing checks every platform's name, version, and binary before registry requests, supports absolute output paths, and rejects unsupported zapi flags instead of silently ignoring them. npm options go after--.Without package-selection flags, zapi still prepares both package types and publishes platforms before the wrapper. The README documents the lifecycle, retry behavior, and Lerna integration.