feat(common): warn when a declared ui-* peer range excludes the installed version - #229
Merged
Merged
Conversation
…d version check-peers compared only the minimum a range admits, mirroring validatePeerVersions, so drift in the other direction was invisible: an adapter declaring ^2.0.0 against an installed 4.0.1 satisfies its own runtime check and still cannot be installed, because a package manager reads the range rather than the baked minimum. rangeAdmits resolves a declared range against a version with its upper bound intact, returning null for syntax it does not model so nothing is guessed at. Such pairs become a warning with code outdated-range; ok and the exit code stay driven by errors alone.
The summary returned early when the check passed, so a warning-only result printed the green line and nothing else. Warnings and remediation now print in both branches, and each issue carries its code.
✅ Deploy Preview for openzeppelin-ui ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
oz-ui-dev check-peersexists to catch "the one adapter/peer mismatch that no build stepcatches". It compares the minimum each declared
@openzeppelin/ui-*range admits againstthe version actually installed, deliberately mirroring
validatePeerVersionsin@openzeppelin/ui-utils.That is right for the failure it was built for — an installed peer that is too old — but it
leaves the opposite drift completely invisible, and that drift is its own defect. An adapter
declaring
^2.0.0against an installed4.0.1:validatePeerVersionscheck, which only enforces>=2.0.0;check-peerstoday, by design;range, not the baked minimum.
Nothing anywhere reported it. That is how every package in
OpenZeppelin/openzeppelin-adapterscame to declare
ui-components,ui-reactandui-utilson the v2 line while the kit shippedcomponents 3.9.0 / react 3.3.2 / utils 4.0.1 — for two majors, in silence. The existing test
adapterPeers.test.tslocked that exact case in as a pass (^2.0.0declared,4.0.0installed), so the blind spot was documented rather than noticed.
What this does
Such pairs are now a warning, code
outdated-range, naming the bump that fixes each one:That output is from a fixture reproducing the adapters' pre-fix state exactly.
ui-types^3.5.0against installed3.5.2stays quiet, as it should. The three bumps it names are thethree the adapters repo has since landed.
rangeAdmits(range, version)resolves a declared range with its upper bound intact:^(including the 0.x leftmost-non-zero rule),~, the four inequalities, exact pins,wildcards, and
||unions. Anything else returnsnulland is left unreported ratherthan guessed at — a false warning here would be worse than none.
AdapterPeerPairgainsrange(as declared) andrangeSatisfied(boolean | null).printAdapterPeerResultprinted the green line and returned early, so a warning-only resultshowed nothing. Warnings and remediation now print on both paths.
What this deliberately does not change
okand the exit code are still driven by errors alone(
issues.every(i => i.severity !== 'error'), matchinglocalDev.ts). Adding this to apipeline already running
check-peerscannot change its result. A clean run prints exactlywhat it printed before.
validatePeerVersionsis not touched. Giving the runtime check an upper bound would turntoday's benign over-install into a hard throw for consumers on a newer kit, and would need
the adapters to pass the range rather than the baked minimum. Catching this statically, at
install/CI time, is the cheaper and safer half; the runtime change is a separate decision.
Checks
Run at the repository root, exit codes captured directly:
pnpm buildpnpm testpnpm typecheckpnpm lintpnpm format:checkAlso ran the built CLI against
OpenZeppelin/openzeppelin-adapterspost-fix: passes clean,20 adapter/peer pairs, no warnings.
Context
This is the only change the UIKit side needed. The adapters' entire UIKit surface — 26
identifiers from
ui-components, 6 fromui-react, 29 fromui-utils— has no breakingchange across v2 -> v3; 29 of the 30 components and hooks are byte-identical source, and the
one exception (
AddressDisplay) is purely additive and inert without injection. The defect wasthe ranges, and the missing signal about them.