fix(export): sync export versions with the published adapter and UI releases - #414
Merged
Conversation
…eleases check-versions is failing on every PR again. This is the same maintenance the script exists for, not a new defect: @openzeppelin/adapter-evm, adapter-polkadot and adapter-stellar published 3.0.0, and the openzeppelin-ui packages published a round (ui-utils 4.0.0, ui-types 3.5.1, ui-components 3.8.2, ui-react 3.3.1, ui-renderer 3.4.1, ui-storage 1.2.4), so versions.ts went stale. Ran `pnpm run update-export-versions`, which updated versions.ts and refreshed two export snapshots. Unlike before, the pin test no longer duplicates these literals (it derives them from packageVersions since #412), so nothing had to be edited by hand and the deadlock did not recur. Note this raises exported apps to the adapter 3.x line while this repo's own devDependencies still pin ^2.x. That gap is what the follow-up adapter bump wave is for; syncing here is what unblocks CI now. Verified: 46 test files and 322 tests pass, the production build succeeds, lint and format:check clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pasevin
added a commit
that referenced
this pull request
Aug 21, 2026
check-versions blocks this PR otherwise. The adapters published again for the AGPL-3.0 licence correction, taking adapter-evm and adapter-stellar to 4.0.0 and adapter-midnight and adapter-solana from 2.2.0 to 4.0.0, so versions.ts went stale within minutes of #414 syncing it to the 3.x line. Ran `pnpm run update-export-versions`: versions.ts plus one export snapshot. Included here rather than as a fourth sync PR because it is the only thing standing between this guard and a green build, and the sync is entirely tool-generated. Verified: `update-export-versions` exits 0 and leaves versions.ts stable against npm, 46 test files and 322 tests pass, the dependency licence guard passes. Note the systemic issue: this is the third time versions.ts drift has blocked an unrelated PR. The job gates every PR on the state of the npm registry, so any publish anywhere in the org turns the next unrelated PR red. Worth reconsidering whether it should gate PRs at all rather than run on a schedule or at release time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pasevin
added a commit
that referenced
this pull request
Aug 21, 2026
) * ci: guard against the removed Trezor and Reown dependency families @trezor/* (Trezor Reference Source License, no redistribution) and @reown/* (Reown Community License, fees above 500 monthly active users plus mandatory-gateway and confidentiality clauses) were both removed from this repo. Neither is a direct dependency: Trezor arrives via @creit.tech/stellar-wallets-kit and Reown via @walletconnect/ethereum-provider, which @wagmi/connectors declares as a hard dependency. That is why they went unnoticed originally -- a grep of source code surfaces neither, and a routine dependency bump can reintroduce them silently. The guard checks both the outcome and the mechanism: - No @trezor/*, @reown/* or @walletconnect/* reference may appear in pnpm-lock.yaml. @walletconnect/* is Apache-2.0 on its own, but it is the only route Reown takes into the tree, so it is banned too. - .pnpmfile.cjs must still define *and* call both strip hooks, so deleting one fails loudly rather than waiting for the next resolution to reintroduce the packages. Runs as an early CI step, invoked directly with node rather than through pnpm: it is lockfile-only and needs no node_modules, so it fails fast. `pnpm check-licenses` is wired up for local use. Verified against all three failure modes, not just the happy path: a banned entry in the lockfile fails, deleting a hook call fails, and deleting a hook definition fails. The call check is anchored to line start deliberately -- unanchored, the function declaration itself satisfies it, and an earlier version of this script passed while the hook was uncalled. Mirrors openzeppelin-adapters#76. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(export): sync export versions with the AGPL adapter release check-versions blocks this PR otherwise. The adapters published again for the AGPL-3.0 licence correction, taking adapter-evm and adapter-stellar to 4.0.0 and adapter-midnight and adapter-solana from 2.2.0 to 4.0.0, so versions.ts went stale within minutes of #414 syncing it to the 3.x line. Ran `pnpm run update-export-versions`: versions.ts plus one export snapshot. Included here rather than as a fourth sync PR because it is the only thing standing between this guard and a green build, and the sync is entirely tool-generated. Verified: `update-export-versions` exits 0 and leaves versions.ts stable against npm, 46 test files and 322 tests pass, the dependency licence guard passes. Note the systemic issue: this is the third time versions.ts drift has blocked an unrelated PR. The job gates every PR on the state of the npm registry, so any publish anywhere in the org turns the next unrelated PR red. Worth reconsidering whether it should gate PRs at all rather than run on a schedule or at release time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Problem
check-versionsis failing on every PR again (seen on #413). This is the maintenance the script exists for, not a new defect:@openzeppelin/adapter-evm,adapter-polkadot,adapter-stellarpublished 3.0.0ui-utils4.0.0,ui-types3.5.1,ui-components3.8.2,ui-react3.3.1,ui-renderer3.4.1,ui-storage1.2.4so
versions.tswent stale and the job's "Check for changes" step fails:Fix
Ran
pnpm run update-export-versions. It updatedversions.tsand refreshed two export snapshots.Worth noting the deadlock from last time did not recur: since #412 the pin test derives its expectations from
packageVersionsinstead of duplicating the literals, so the sync script's own snapshot refresh no longer trips over a contradictory assertion. Nothing needed hand-editing.Verification
pnpm run update-export-versionsexits 0 and leavesversions.tsstable (the condition the CI job checks)format:checkcleanTwo things for reviewers
1. This raises exported apps to the adapter 3.x line while this repo's own
devDependenciesstill pin^2.x. So generated apps get adapter 3.x while the builder previews with 2.x — across a major boundary. That is what the follow-up adapter bump wave is for; syncing here is what unblocks CI now. Flagging it rather than folding a breaking dependency upgrade into a CI unblock.2. There is a flaky test unrelated to this change.
useContractForm.reset-guard.test.tsxintermittently throwsEnvironmentTeardownError: Cannot load '/src/export/assemblers/addCoreTemplateFiles.ts' … after the environment was torn down. All 322 tests still pass, but the unhandled error makes vitest exit 1, which failscheck-versionson its own. It reproduces locally, so it is not CI-specific — that is what the first failure on #413 actually was, before this drift surfaced underneath it. Worth fixing separately: it will keep causing spurious release/CI failures.