chore(ci): guard adapter peer versions in CI - #418
Merged
Conversation
This repo had no peer guard. Its pins are currently correct -- 15 of 15 adapter/peer pairs satisfied -- but nothing was stopping an adapter bump from leaving the @OpenZeppelin/ui-* pins behind. The adapters enforce those minimums only at runtime, inside validatePeerVersions, so a stale pin passes build, typecheck, test and lint and then fails in the browser with the network runtime stuck failed. That is how the same mismatch reached rwa-wizard staging. Uses the shared oz-ui-dev check-peers command rather than a local script, so there is no per-repo copy to drift. It resolves scope directories from pnpm-workspace.yaml, which matters here: dependencies land both at the root and under apps/builder. Requires ui-dev-cli >=1.2.0, which is where check-peers lands. The only major change in 1.x is the Node engine floor >=22.13.0, which this repo already declares. The lockfile is intentionally not regenerated: 1.2.0 is unpublished, so pnpm cannot resolve it yet.
check-peers shipped in @openzeppelin/ui-dev-cli 1.3.0, so the branch no longer points at an unpublished version.
The pre-push hook syncs versions.ts against the registry and refuses the push otherwise. This branch predates the adapter 5.x release, so its pins were stale. The values match the ones on fix/drop-metamask-sdk exactly, so the two branches merge without conflict.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
@openzeppelin/adapter-*packages declare peerDependencies on@openzeppelin/ui-*but enforce them only at runtime, insidevalidatePeerVersions(). A repo that bumps the adapters without moving itsui-*pins passes typecheck, tests, build and lint, then fails in the browser with the network runtime stuck failed.This repo had no guard against that. Its pins are correct today, but nothing would catch the next adapter major that moves a peer floor — it would land in staging instead of CI.
Changes
oz-ui-dev check-peers --project "$PWD"check-adapter-peersnpm script for running it locally@openzeppelin/ui-dev-cli→^1.3.0, the first published line carrying the commandversions.tssynced to the published registry versions (the pre-push hook enforces this and refuses the push otherwise)Why the shared command rather than a local script
role-manager and rwa-wizard each carried a copy of this script. Both hardcoded
node_modules/@openzeppelinat the repo root — which is why a straight copy into this repo failed outright, since dependencies here install underapps/builder. The shared command reuses the CLI'scollectWorkspacePackageDirs, expandingpnpm-workspace.yamlglobs, so it scans the root and every workspace package. A third copy would also have been a third thing to drift; the existing two already had.Verification
pnpm exec oz-ui-dev check-peers→ passes, 15 adapter/peer pairs, resolving underapps/builder/node_modules— the layout that broke the old scriptversions.tssync (9 tests)Merge order
Merge after #417 in this repo. Both touch
ui-dev-cliandversions.ts; theversions.tscontent is byte-identical between the two branches, so it merges cleanly, and theui-dev-cliline is a one-line conflict at worst.