Update dependency @patternfly/react-core to v6.6.1 - autoclosed - #188
red-hat-konflux[bot] wants to merge 1 commit into
Conversation
|
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Amber reviewStatus: Complete VerdictCOMMENT (recommend changes before merge). This is a low-risk Renovate patch bump of Hi, Amber here. I reviewed the single-line dependency change against the HyperShell conventions (notably "image/dependency references must match across the stack") and cross-checked the other open PRs for coordination issues. SummaryThe change itself is a valid conventional-commit patch bump and carries little functional risk for a PatternFly patch release. My concern is consistency: Findings[Major] Intra-package version split for [Major] Consumer [Minor] Sibling PatternFly packages left out of lockstep — [Info] Lockfile unchanged — Cross-PR coordinationI compared this PR against the other open PRs in
No material cross-PR conflict beyond the #189 lockstep coordination above. Recommended actionUpdate Findings Summary (ordered by severity, highest first):
Convention Checklist:
|
jsell-rh
left a comment
jsell-rh
left a comment
There was a problem hiding this comment.
Verdict
COMMENT (recommend changes before merge). This is a low-risk Renovate patch bump of @patternfly/react-core 6.6.0 -> 6.6.1, but it only updates the peerDependencies entry and leaves the package's own devDependency and the consuming web-console at 6.6.0, creating a PatternFly version split across the stack that should be resolved before merge.
Hi, Amber here. I reviewed the single-line dependency change against the HyperShell conventions (notably "image/dependency references must match across the stack") and cross-checked the other open PRs for coordination issues.
Summary
The change itself is a valid conventional-commit patch bump and carries little functional risk for a PatternFly patch release. My concern is consistency: @patternfly/react-core is now declared at two different versions inside the same package.json, its sibling PatternFly packages stay at 6.6.0, and the only consumer (web-console) still provides 6.6.0, so the newly-declared peer requirement is not actually satisfied anywhere in the workspace.
Findings
[Major] Intra-package version split for @patternfly/react-core — peerDependencies was bumped to 6.6.1 (line 24) but devDependencies still pins 6.6.0 (line 36). The package is therefore built and tested against 6.6.0 while declaring it needs 6.6.1 from consumers. These two entries should move together. Convention: dependency references must match across the stack. Confidence: High.
[Major] Consumer web-console still provides 6.6.0 -> unmet peer — components/web-console/package.json:34 pins @patternfly/react-core: 6.6.0. Because the peer requirement here is an exact pin (6.6.1), the sole workspace consumer no longer satisfies it, which will surface as an unmet-peer warning/resolution mismatch. Either bump the consumer too or land this with the coordinated set (see Cross-PR section). Confidence: Medium-High.
[Minor] Sibling PatternFly packages left out of lockstep — @patternfly/react-icons and @patternfly/react-table remain 6.6.0 in both peerDependencies and devDependencies. PatternFly expects @patternfly/* to be installed at matching versions; mixing 6.6.1 core with 6.6.0 icons/table is usually fine within a patch line but is best kept in lockstep. Confidence: Medium.
[Info] Lockfile unchanged — pnpm-lock.yaml still records 6.6.0. pnpm does not enumerate peerDependencies in importer snapshots, so a frozen-lockfile install is unlikely to break from this change alone; I mention it only so a maintainer can confirm CI stays green. Confidence: Low.
Cross-PR coordination
I compared this PR against the other open PRs in openshift-online/hypershell. Open PRs at review time: #216, #214, #212, #211, #210, #209, #208, #207, #206, #201, #200, #194, #189, #188 (this PR), #185, #182, #179, #151, #150, #148, #135, #109, #75, #73.
- #189
chore(deps): update dependency @patternfly/react-icons to v6.6.1— material coordination. #189 is a sibling PatternFly bump that edits the same file and the samepeerDependenciesblock (packages/gateway-management-ui/package.json), moving@patternfly/react-icons6.6.0 -> 6.6.1. Together, #188 + #189 (plus areact-tablebump) constitute one lockstep PatternFly6.6.1upgrade. Landing #188 alone leaves the PatternFly family mismatched (core6.6.1, icons/table6.6.0), and neither PR touches thedevDependenciesor theweb-consoleconsumer. Maintainer decision needed: land these PatternFly bumps as a coordinated set (and includereact-table, thedevDependency, and theweb-consolepin) rather than piecemeal. This is a plan/ordering coordination, not merely the text merge conflict that will also occur on second merge. - #135
chore(deps): update dependency react-intl to v10.1.20— no material conflict. It edits the samepackage.jsonpeerDependenciesblock but a different, unrelated package (react-intl). The only overlap is a routine text merge on the second merge; there is no design, data-model, interface, or ordering conflict. - UI/web-console PRs (#216, #214, #210, #209, #208, #207) — no material conflict. These add/modify UI features that consume PatternFly but do not change its version. A PatternFly patch bump is not expected to alter public component APIs, so there is no incompatible design or competing interface change.
- All other open PRs (control-plane, auth, e2e, images, docs, Go/container dependency bumps) touch unrelated areas with no goal, ownership, data-model, or ordering conflict with this frontend dependency bump.
No material cross-PR conflict beyond the #189 lockstep coordination above.
Recommended action
Update devDependencies @patternfly/react-core to 6.6.1 in this same file, and coordinate with #189 (and a react-table bump + the web-console consumer pin) so the entire PatternFly family lands at 6.6.1 together. Rollback is trivial: revert this one-line change.
Findings Summary (ordered by severity, highest first):
- [Major]
@patternfly/react-coresplit acrosspeerDependencies(6.6.1) anddevDependencies(6.6.0) - Dependency Consistency (L24, L36) - [Major] Consumer
web-consolestill pins 6.6.0, leaving the new exact peer requirement unsatisfied - Dependency Consistency (components/web-console/package.json:34) - [Minor] Sibling
@patternfly/react-icons/@patternfly/react-tableleft at 6.6.0, breaking PatternFly lockstep - Dependency Consistency (L25-26) - [Info]
pnpm-lock.yamlunchanged; confirm frozen-lockfile CI stays green - Build Hygiene
Convention Checklist:
| Convention | Result |
|---|---|
| Conventional commit message | Pass |
| Dependency references match across the stack | Fail |
| Config separate from code | Pass |
| No secrets in logs/responses | N/A (no code change) |
| }, | ||
| "peerDependencies": { | ||
| "@patternfly/react-core": "6.6.0", | ||
| "@patternfly/react-core": "6.6.1", |
There was a problem hiding this comment.
[Major] Version split within this file. This peerDependencies entry is now @patternfly/react-core: 6.6.1, but the devDependencies entry (line 36) still pins 6.6.0, so the package is built/tested against 6.6.0 while declaring it needs 6.6.1 from consumers. Bump the devDependency in the same change so both match. Also note the sole consumer components/web-console/package.json:34 still provides 6.6.0, which no longer satisfies this exact peer pin. Consider landing together with #189 (react-icons 6.6.1) and a react-table bump to keep the PatternFly family in lockstep.
7962e09 to
22d7329
Compare
Amber reviewStatus: Complete VerdictREQUEST_CHANGES This Renovate PR bumps only the Findings[Critical] Exact peer pin
[Minor] PatternFly package family left version-skewed — Dependency Integrity (
Cross-PR coordinationThe sibling dependency bumps for Findings Summary (ordered by severity, highest first)
Convention Checklist
|
jsell-rh
left a comment
jsell-rh
left a comment
There was a problem hiding this comment.
Verdict
REQUEST_CHANGES
This Renovate PR bumps only the @patternfly/react-core peerDependency in the shared gateway-management-ui package to an exact 6.6.1, but leaves the package's own devDependency and the web-console consumer at 6.6.0. With strictPeerDependencies: true and saveExact: true in pnpm-workspace.yaml, this partial bump produces an invalid (version-mismatched) peer dependency, which will fail pnpm install/check rather than emit a mere warning.
Findings
[Critical] Exact peer pin 6.6.1 is unsatisfiable by the co-located devDependency and the consumer (still 6.6.0) — Dependency Integrity (packages/gateway-management-ui/package.json L24)
- The peerDependency is now pinned to exactly
6.6.1, but:- the same file's
devDependencies["@patternfly/react-core"]is still6.6.0(L36), so the package is built/tested against a version that does not satisfy its own advertised peer; - the only consumer,
components/web-console/package.json, pins@patternfly/react-coreto6.6.0(L34) and injects this workspace package (injectWorkspacePackages: true).
- the same file's
pnpm-workspace.yamlsetsstrictPeerDependencies: true. A mismatched peer (6.6.0provided vs exact6.6.1required) is treated as invalid, andautoInstallPeerswill not resolve a conflicting second copy when a direct provider exists at a different version. The likely result is a failing install/pnpm --filter ... check.- Fix: bump
@patternfly/react-coreto6.6.1in the same file'sdevDependencies(L36) and incomponents/web-console/package.json(L34) in the same change, and regenerate the lockfile if needed, so all providers match the peer requirement. Confidence: Medium-High.
[Minor] PatternFly package family left version-skewed — Dependency Integrity (packages/gateway-management-ui/package.json L24-26)
@patternfly/react-iconsand@patternfly/react-tableremain at6.6.0whilereact-coremoves to6.6.1. PatternFly ships these as a matched set and expects them aligned within a release; bumping only one leaves the trio skewed. Keep the three PatternFly packages on the same version. Confidence: Medium.
Cross-PR coordination
The sibling dependency bumps for @patternfly/react-icons (#189) and @patternfly/react-table (#225) each raise only their own peerDependency line in this same shared package to 6.6.1, leaving the other two PatternFly packages, the local devDependencies, and the web-console consumer at 6.6.0. Under strictPeerDependencies: true with exact pins, merging any one of these in isolation yields an intermediate state with a version-skewed PatternFly family and unsatisfiable exact peers, which breaks pnpm install. Maintainers should decide to treat #188/#189/#225 as one coordinated, version-aligned change set (including the matching devDependency and web-console consumer bumps) rather than merging them independently.
Findings Summary (ordered by severity, highest first)
- [Critical] Exact peer pin
6.6.1unsatisfiable by devDependency + consumer at6.6.0understrictPeerDependencies- Dependency Integrity (L24, L36) - [Minor] PatternFly react-icons/react-table left at
6.6.0while react-core moves to6.6.1- Dependency Integrity (L24-26)
Convention Checklist
| Convention | Result |
|---|---|
| Conventional commit message | Pass |
| Dependency versions aligned across peer/dev/consumer (strict peers) | Fail |
| PatternFly package family kept on a single version | Fail |
| Lockfile in sync with manifest (peer-only edit not tracked in importer lockfile) | Pass |
| }, | ||
| "peerDependencies": { | ||
| "@patternfly/react-core": "6.6.0", | ||
| "@patternfly/react-core": "6.6.1", |
There was a problem hiding this comment.
[Critical] Exact peer pin unsatisfiable under strict peer resolution.
This raises the @patternfly/react-core peerDependency to an exact 6.6.1, but the same file still declares devDependencies["@patternfly/react-core"] = 6.6.0 (L36) and the only consumer, components/web-console/package.json, pins 6.6.0 (L34). With strictPeerDependencies: true and saveExact: true, a version-mismatched peer is treated as invalid and will fail pnpm install/check, not just warn.
Fix: bump the devDependency here (L36) and the web-console dependency (L34) to 6.6.1 in the same change, and align react-icons/react-table so the PatternFly family stays on one version.
22d7329 to
a2f00c2
Compare
Amber reviewStatus: Complete |
jsell-rh
left a comment
jsell-rh
left a comment
There was a problem hiding this comment.
Verdict
COMMENT. This is a safe Renovate patch bump of @patternfly/react-core from 6.6.0 to 6.6.1 in the gateway-management-ui peer dependency. The diff itself carries no security, error-handling, or reconciliation concerns; the only substantive notes are an internal version-consistency gap and a set of sibling PatternFly bumps that need to land together.
The change touches a single line in packages/gateway-management-ui/package.json. It is a private React package's peerDependencies declaration, so there is no Go, control-plane, secret, or pod-spec surface to evaluate. pnpm-lock.yaml was not modified, which is expected: pnpm lockfile v9 does not record workspace peerDependencies in the importer sections, so --frozen-lockfile installs remain consistent.
Findings
[Minor] Peer requirement diverges from what the package actually builds/tests against - packages/gateway-management-ui/package.json
The bump only touches the peerDependencies entry (line 24 -> 6.6.1). The package's own devDependencies entry for @patternfly/react-core stays at 6.6.0 (line 36), and the actual consumer, components/web-console/package.json, still pins 6.6.0. Net effect: the package now declares a peer floor of 6.6.1 that is never exercised by its own build/test toolchain and is not satisfied by the in-repo consumer. Because strict-peer-dependencies is not enabled (no .npmrc, lockfile shows only autoInstallPeers: true), this surfaces as a peer warning rather than a CI failure, so it is low impact. Consider bumping the devDependencies entry (and, if intended, the web-console consumer) to 6.6.1 so the declared peer contract matches what is compiled and tested. Confidence: High.
Cross-PR coordination
Two other open pull requests raise the sibling PatternFly packages @patternfly/react-icons and @patternfly/react-table to the same 6.6.1 in the same peerDependencies block of packages/gateway-management-ui/package.json. PatternFly expects @patternfly/* core/icons/table to move in lockstep on one version; merging any of these individually leaves the trio mismatched (e.g. core 6.6.1, icons/table 6.6.0). Maintainers should decide to land these as a coordinated set at 6.6.1, and because all three edit the same adjacent lines, whichever merges first will force the others to rebase before they can merge.
- PR #189 (
@patternfly/react-icons->6.6.1): merge together with this PR to keep PatternFly in lockstep; rebase after the first of the set lands. - PR #225 (
@patternfly/react-table->6.6.1): same coordination and rebase requirement.
Findings Summary (ordered by severity, highest first)
- [Minor] Peer dependency bumped to
6.6.1while devDependency and in-repo consumer remain6.6.0, so the declared peer floor is untested and unmet - Dependency Consistency (L24, L36)
Convention Checklist
| Convention | Result |
|---|---|
| Conventional commit message | Pass |
| Config separate from code (no code change needed) | Pass |
| Image/version references consistent across the stack | Fail |
| Lockfile consistent with manifest | Pass |
| }, | ||
| "peerDependencies": { | ||
| "@patternfly/react-core": "6.6.0", | ||
| "@patternfly/react-core": "6.6.1", |
There was a problem hiding this comment.
[Minor] Peer floor now diverges from what is built/tested. This bumps the peerDependencies entry to 6.6.1, but the package's own devDependencies entry for @patternfly/react-core (line 36) stays at 6.6.0, and the actual consumer components/web-console/package.json still pins 6.6.0. So the new peer floor (6.6.1) is neither exercised by this package's build/test toolchain nor satisfied by the in-repo consumer. strict-peer-dependencies is not enabled, so this is a peer warning rather than a CI failure, but consider bumping the devDependency (and, if intended, the consumer) to 6.6.1 so the declared contract matches what is compiled and tested.
Amber reviewStatus: Complete |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
a2f00c2 to
9708a02
Compare
Amber reviewStatus: Complete |
red-hat-konflux
Bot
changed the title
amber-review-bot
left a comment
amber-review-bot
left a comment
There was a problem hiding this comment.
Verdict
This Renovate bump moves @patternfly/react-core to 6.6.1 in the peerDependencies of two workspace packages, but the change is incomplete: pnpm-lock.yaml was not regenerated and the matching devDependencies were left at 6.6.0, so the repo is in an inconsistent state that will fail CI. I recommend REQUEST_CHANGES until the lockfile and dev/peer versions are reconciled.
Summary
The intent (patch bump of a UI dependency) is fine, but the PR as committed does not update pnpm-lock.yaml and leaves the devDependencies entry behind. Every CI job installs with pnpm install --frozen-lockfile, which will reject a lockfile whose recorded specifier (6.6.0) no longer matches package.json (6.6.1).
Findings
[Major] Lockfile not regenerated - --frozen-lockfile will fail CI
pnpm-lock.yaml still records specifier: 6.6.0 / version: 6.6.0(...) for @patternfly/react-core in both importer entries, and @patternfly/react-core@6.6.1 is absent from the lockfile entirely (the only 6.6.1 entries are the transitive react-styles/react-tokens). The workflows in .github/workflows/checks.yml, unit-tests.yml, e2e.yml, architecture-site.yml, and the Makefile all run pnpm install --frozen-lockfile, which fails with ERR_PNPM_OUTDATED_LOCKFILE when the manifest specifier and the lockfile disagree. Fix: run pnpm install --lockfile-only (or a normal install) and commit the updated pnpm-lock.yaml. Confidence: High.
[Minor] devDependencies left at 6.6.0 while peerDependencies moved to 6.6.1
In both packages/gateway-management-ui/package.json and packages/operational-dashboard-ui/package.json, peerDependencies.@patternfly/react-core is now 6.6.1 but devDependencies.@patternfly/react-core is still 6.6.0. Since the devDependency is what is actually installed to build and test each package, the code is exercised against 6.6.0 while declaring a hard peer requirement of 6.6.1. Align both to the same version. Confidence: High.
Cross-PR coordination
The PatternFly React packages (react-core, react-icons, react-table) are a matched family that PatternFly expects to move together, and each is currently being bumped to 6.6.1 in separate PRs against the same workspace manifests and the shared pnpm-lock.yaml. PR #189 (react-icons -> 6.6.1) and PR #225 (react-table -> 6.6.1) therefore need coordination with this one: maintainers should decide to land them together (and regenerate the shared lockfile once) so the PatternFly family stays version-aligned and so the second/third PR does not have to rebase a lockfile the first one rewrote. Merging any one alone leaves react-core/react-icons/react-table on mismatched versions.
Findings Summary (ordered by severity, highest first)
- [Major]
pnpm-lock.yamlnot regenerated;--frozen-lockfileinstalls in CI will fail - Build / Dependency Consistency (packages/gateway-management-ui/package.json:24, packages/operational-dashboard-ui/package.json:22) - [Minor]
devDependenciesreact-core still 6.6.0 while peerDependency moved to 6.6.1 - Dependency Consistency (packages/gateway-management-ui/package.json:24,36; packages/operational-dashboard-ui/package.json:22,41)
Convention Checklist
| Convention | Result |
|---|---|
| Conventional commit message | Pass |
| Dependency manifest and lockfile in sync | Fail |
| Dependency versions consistent within package (dev vs peer) | Fail |
| No em dashes in text files | Pass |
| }, | ||
| "peerDependencies": { | ||
| "@patternfly/react-core": "6.6.0", | ||
| "@patternfly/react-core": "6.6.1", |
There was a problem hiding this comment.
[Major] pnpm-lock.yaml was not regenerated for this bump. The lockfile still records specifier: 6.6.0 for @patternfly/react-core in this package's importer, and 6.6.1 of react-core is not present in the lockfile at all. Because CI installs with pnpm install --frozen-lockfile (checks.yml, unit-tests.yml, e2e.yml, Makefile), this mismatch will fail with ERR_PNPM_OUTDATED_LOCKFILE. Run pnpm install --lockfile-only and commit pnpm-lock.yaml.
[Minor] devDependencies.@patternfly/react-core (line 36) is still 6.6.0; it is the devDependency that is actually installed to build/test this package, so it should move to 6.6.1 alongside the peer requirement.
| "@openshift-online/hypershell-domain-probes": "workspace:0.0.0", | ||
| "@patternfly/react-charts": "8.6.1", | ||
| "@patternfly/react-core": "6.6.0", | ||
| "@patternfly/react-core": "6.6.1", |
There was a problem hiding this comment.
[Major] Same lockfile issue as the sibling package: pnpm-lock.yaml still pins @patternfly/react-core at 6.6.0 for this importer, so pnpm install --frozen-lockfile in CI will fail. Regenerate and commit the lockfile.
[Minor] devDependencies.@patternfly/react-core (line 41) remains 6.6.0 while this peer entry is now 6.6.1; align them.
amber-review-bot
added
the
amber/changes-requested
red-hat-konflux
Bot
changed the title
2 participants
This PR contains the following updates:
6.6.0→6.6.1Warning
Some dependencies could not be looked up. Check the warning logs for more information.
Release Notes
patternfly/patternfly-react (@patternfly/react-core)
v6.6.1Compare Source
Configuration
📅 Schedule: (in timezone America/New_York)
* 0-7 * * 1)🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
To execute skipped test pipelines write comment
/ok-to-test.Documentation
Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.