chore(deps): update dependency @patternfly/react-icons to v6.6.1

[red-hat-konflux]

This PR contains the following updates:

Package	Change	Age	Confidence
@patternfly/react-icons	6.6.0 → 6.6.1

---

Warning

Some dependencies could not be looked up. Check the warning logs for more information.

---

Release Notes

patternfly/patternfly-react (@​patternfly/react-icons)

v6.6.1

Compare Source

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • Between 12:00 AM and 07:59 AM, only on Monday (* 0-7 * * 1)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

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.

[red-hat-konflux]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: pnpm-lock.yaml

[ERR_PNPM_UNSUPPORTED_ENGINE] Unsupported environment (bad pnpm and/or Node.js version)

Your Node version is incompatible with "/tmp/renovate/repos/github/openshift-online/hypershell".

Expected version: >=24.18.1
Got: v24.11.0

This is happening because the package's manifest has an engines.node field specified.
To fix this issue, install the required Node version.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 7a1bcced-147c-4816-ac3d-118679c8453c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[jsell-rh]

Amber review

Status: Complete

Verdict

COMMENT — no blockers. This is a low-risk, single-line Renovate/MintMaker bump of @patternfly/react-icons from 6.6.0 to 6.6.1 in the reusable gateway-management-ui package. The only issue is an intra-file version drift: the peerDependencies entry was bumped but the matching devDependencies entry (and the lockfile resolution) stayed at 6.6.0, so the package is not actually built/tested against the version it now declares it needs.

Amber Analysis

A dependency-only change with no Go/security/reconciler surface, so the HyperShell backend conventions (panic-free, error wrapping, SecurityContext, reconcile pattern, secret handling) are N/A here. The change is safe to ship; my one substantive note is a consistency gap that Renovate would normally have handled by moving both the peer and dev entries together.

Findings

[Minor] peerDependencies and devDependencies for @patternfly/react-icons now disagree — Dependency consistency (packages/gateway-management-ui/package.json L25 vs L37)

• peerDependencies["@patternfly/react-icons"] is bumped to 6.6.1 (L25), but devDependencies["@patternfly/react-icons"] remains 6.6.0 (L37), and pnpm-lock.yaml still resolves react-icons to 6.6.0 (importer specifier 6.6.0, resolution @patternfly/react-icons@6.6.0).
• Effect: this package declares that consumers must supply 6.6.1, yet it is compiled/type-checked/tested against 6.6.0. That is the exact version it is asking downstream (web-console) to install, so it is validated against a different version than it advertises.
• No CI break is expected from this alone: pnpm's lockfile tracks only dependencies/devDependencies specifiers, not peerDependencies, so --frozen-lockfile should still pass. But the drift is real and defeats the point of the bump.
• Fix: bump devDependencies["@patternfly/react-icons"] to 6.6.1 as well and regenerate pnpm-lock.yaml in the same PR, so dev/peer/lock all agree. Confidence: High.

Cross-PR coordination

I reviewed all other open PRs in openshift-online/hypershell (see list below). No material logical/structural/plan conflict with #189 was found — no duplicate solution, incompatible design, competing interface, or required change-ordering. There is one worth-noting coordination point:

• chore(deps): update dependency @patternfly/react-core to v6.6.1 #188 chore(deps): update dependency @patternfly/react-core to v6.6.1 touches the same peerDependencies block in the same file (packages/gateway-management-ui/package.json) and uses the identical partial-update pattern: it bumps only the peer entry to 6.6.1 and leaves the devDependencies entry at 6.6.0. This is complementary, not competing — the two PRs move different PatternFly sub-packages. The coordination question for maintainers is ecosystem lockstep: PatternFly react-core/react-icons/react-table are expected to share a version, so after both merge you would have react-core@6.6.1 + react-icons@6.6.1 but react-table still 6.6.0, plus dev/peer drift in both. Suggest batching the PatternFly 6.6.1 bumps (and bumping react-table + the dev entries + lockfile together) rather than landing them piecemeal. This is a coordination preference, not a blocking design decision.
• chore(deps): update dependency react-intl to v10.1.20 #135 chore(deps): update dependency react-intl to v10.1.20 also edits the same file but a different (react-intl) line. Only a trivial textual rebase overlap — not a material conflict.
• Other PRs that touch packages/gateway-management-ui/ ([HYPERSHELL-129] feat(web-console): Adding section to gateway UI with instructions for sandbox connecting #208, [HYPERSHELL-259] feat: reconcile gateway version for CLI installation #210, fix(kind): expose gateway metrics and fix control plane connectivity #211, HYPERSHELL-112 Dashboard UI #209, Hypershell-112 UI with adjustments #214) modify source files under src/, not package.json, so they do not interact with this dependency pin.

Bottom line: no material cross-PR conflict; the only actionable coordination is aligning the PatternFly 6.6.1 bumps (#188/#189) so dev/peer/lock and sibling packages stay in lockstep.

Other open PRs reviewed for conflicts

#73, #75, #109, #135, #148, #150, #151, #179, #182, #185, #188, #194, #200, #201, #206, #207, #208, #209, #210, #211, #212, #214, #216.

Findings Summary (ordered by severity, highest first)

1. [Minor] peerDependencies react-icons bumped to 6.6.1 while devDependencies + lockfile stay at 6.6.0 — Dependency consistency (L25, L37)

Convention Checklist

Convention	Result
Image references consistent across the stack	Pass
Dependency pin consistent within file (peer vs dev vs lock)	Fail
Conventional commit message	Pass

[jsell-rh]

Verdict

COMMENT — no blockers. This is a low-risk, single-line Renovate/MintMaker bump of @patternfly/react-icons from 6.6.0 to 6.6.1 in the reusable gateway-management-ui package. The only issue is an intra-file version drift: the peerDependencies entry was bumped but the matching devDependencies entry (and the lockfile resolution) stayed at 6.6.0, so the package is not actually built/tested against the version it now declares it needs.

Amber Analysis

A dependency-only change with no Go/security/reconciler surface, so the HyperShell backend conventions (panic-free, error wrapping, SecurityContext, reconcile pattern, secret handling) are N/A here. The change is safe to ship; my one substantive note is a consistency gap that Renovate would normally have handled by moving both the peer and dev entries together.

Findings

[Minor] peerDependencies and devDependencies for @patternfly/react-icons now disagree — Dependency consistency (packages/gateway-management-ui/package.json L25 vs L37)

• peerDependencies["@patternfly/react-icons"] is bumped to 6.6.1 (L25), but devDependencies["@patternfly/react-icons"] remains 6.6.0 (L37), and pnpm-lock.yaml still resolves react-icons to 6.6.0 (importer specifier 6.6.0, resolution @patternfly/react-icons@6.6.0).
• Effect: this package declares that consumers must supply 6.6.1, yet it is compiled/type-checked/tested against 6.6.0. That is the exact version it is asking downstream (web-console) to install, so it is validated against a different version than it advertises.
• No CI break is expected from this alone: pnpm's lockfile tracks only dependencies/devDependencies specifiers, not peerDependencies, so --frozen-lockfile should still pass. But the drift is real and defeats the point of the bump.
• Fix: bump devDependencies["@patternfly/react-icons"] to 6.6.1 as well and regenerate pnpm-lock.yaml in the same PR, so dev/peer/lock all agree. Confidence: High.

Cross-PR coordination

I reviewed all other open PRs in openshift-online/hypershell (see list below). No material logical/structural/plan conflict with #189 was found — no duplicate solution, incompatible design, competing interface, or required change-ordering. There is one worth-noting coordination point:

• #188 chore(deps): update dependency @patternfly/react-core to v6.6.1 touches the same peerDependencies block in the same file (packages/gateway-management-ui/package.json) and uses the identical partial-update pattern: it bumps only the peer entry to 6.6.1 and leaves the devDependencies entry at 6.6.0. This is complementary, not competing — the two PRs move different PatternFly sub-packages. The coordination question for maintainers is ecosystem lockstep: PatternFly react-core/react-icons/react-table are expected to share a version, so after both merge you would have react-core@6.6.1 + react-icons@6.6.1 but react-table still 6.6.0, plus dev/peer drift in both. Suggest batching the PatternFly 6.6.1 bumps (and bumping react-table + the dev entries + lockfile together) rather than landing them piecemeal. This is a coordination preference, not a blocking design decision.
• #135 chore(deps): update dependency react-intl to v10.1.20 also edits the same file but a different (react-intl) line. Only a trivial textual rebase overlap — not a material conflict.
• Other PRs that touch packages/gateway-management-ui/ (#208, #210, #211, #209, #214) modify source files under src/, not package.json, so they do not interact with this dependency pin.

Bottom line: no material cross-PR conflict; the only actionable coordination is aligning the PatternFly 6.6.1 bumps (#188/#189) so dev/peer/lock and sibling packages stay in lockstep.

Other open PRs reviewed for conflicts

#73, #75, #109, #135, #148, #150, #151, #179, #182, #185, #188, #194, #200, #201, #206, #207, #208, #209, #210, #211, #212, #214, #216.

Findings Summary (ordered by severity, highest first)

1. [Minor] peerDependencies react-icons bumped to 6.6.1 while devDependencies + lockfile stay at 6.6.0 — Dependency consistency (L25, L37)

Convention Checklist

Convention	Result
Image references consistent across the stack	Pass
Dependency pin consistent within file (peer vs dev vs lock)	Fail
Conventional commit message	Pass

[jsell-rh]

This bumps the peer dependency to 6.6.1, but the devDependencies entry for @patternfly/react-icons (line 37, unchanged) is still 6.6.0, and pnpm-lock.yaml resolves it to 6.6.0. The package therefore declares consumers must supply 6.6.1 while it is itself built and tested against 6.6.0. Bump the dev entry to 6.6.1 and regenerate the lockfile in this PR so peer/dev/lock all agree. (No --frozen-lockfile break expected, since pnpm does not track peerDependencies specifiers in the lockfile.)