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: 4d85ea98-9193-4c96-b3d8-199473913196

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-154 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.)

[jsell-rh]

Amber review

Status: Complete

Verdict

COMMENT - This is a low-risk Renovate patch bump of @patternfly/react-icons (6.6.0 -> 6.6.1) in the reusable gateway UI package. The change is safe to take, but it leaves the package internally inconsistent (peer requires 6.6.1, dev/tested against 6.6.0) and is one of a set of PatternFly bumps that should land together.

Findings

[Minor] peerDependencies and devDependencies diverge for @patternfly/react-icons - Consistency

packages/gateway-management-ui/package.json now declares @patternfly/react-icons": "6.6.1" under peerDependencies (L25) while devDependencies still pins 6.6.0 (L37). Because these are exact pins, the package now advertises a peer requirement for a version it never actually builds or tests against locally (the lockfile still resolves 6.6.0). It also introduces a version skew inside the PatternFly suite, since the sibling @patternfly/react-core and @patternfly/react-table peers remain at 6.6.0. 6.6.1 is a patch release so functional risk is low, but for consistency the devDependencies entry should be bumped to 6.6.1 in the same change (Renovate normally groups these). Confidence: High.

Note: since pnpm does not record peerDependencies specifiers in the lockfile importers section, no pnpm-lock.yaml update is required for this peer-only change; a devDependencies bump would require regenerating the lockfile.

Cross-PR coordination

The PatternFly React packages (@patternfly/react-core, @patternfly/react-icons, @patternfly/react-table) are conventionally kept on a single, lockstep version. Two other open PRs each bump one sibling of this same suite to 6.6.1 in the identical peerDependencies block of packages/gateway-management-ui/package.json: #188 (@patternfly/react-core) and #225 (@patternfly/react-table). Maintainers should decide to land #188, #189, and #225 as a coordinated set so the PatternFly peer versions stay aligned; merging any one alone leaves the suite in a mixed-version state (e.g. icons at 6.6.1 while core/table remain 6.6.0). Because all three edit adjacent lines of the same block, whichever merges first will force the others to rebase - sequence them intentionally rather than merging independently.

Findings Summary (ordered by severity, highest first)

1. [Minor] peerDependencies bumped to 6.6.1 while devDependencies (and lockfile) stay at 6.6.0, and the entry now diverges from the sibling PatternFly peers - Consistency (L25, L37)

Convention Checklist

Convention	Result
Image/dependency references consistent across the stack	Fail
Conventional commit message	Pass

[jsell-rh]

Verdict

COMMENT - This is a low-risk Renovate patch bump of @patternfly/react-icons (6.6.0 -> 6.6.1) in the reusable gateway UI package. The change is safe to take, but it leaves the package internally inconsistent (peer requires 6.6.1, dev/tested against 6.6.0) and is one of a set of PatternFly bumps that should land together.

Findings

[Minor] peerDependencies and devDependencies diverge for @patternfly/react-icons - Consistency

packages/gateway-management-ui/package.json now declares @patternfly/react-icons": "6.6.1" under peerDependencies (L25) while devDependencies still pins 6.6.0 (L37). Because these are exact pins, the package now advertises a peer requirement for a version it never actually builds or tests against locally (the lockfile still resolves 6.6.0). It also introduces a version skew inside the PatternFly suite, since the sibling @patternfly/react-core and @patternfly/react-table peers remain at 6.6.0. 6.6.1 is a patch release so functional risk is low, but for consistency the devDependencies entry should be bumped to 6.6.1 in the same change (Renovate normally groups these). Confidence: High.

Note: since pnpm does not record peerDependencies specifiers in the lockfile importers section, no pnpm-lock.yaml update is required for this peer-only change; a devDependencies bump would require regenerating the lockfile.

Cross-PR coordination

The PatternFly React packages (@patternfly/react-core, @patternfly/react-icons, @patternfly/react-table) are conventionally kept on a single, lockstep version. Two other open PRs each bump one sibling of this same suite to 6.6.1 in the identical peerDependencies block of packages/gateway-management-ui/package.json: #188 (@patternfly/react-core) and #225 (@patternfly/react-table). Maintainers should decide to land #188, #189, and #225 as a coordinated set so the PatternFly peer versions stay aligned; merging any one alone leaves the suite in a mixed-version state (e.g. icons at 6.6.1 while core/table remain 6.6.0). Because all three edit adjacent lines of the same block, whichever merges first will force the others to rebase - sequence them intentionally rather than merging independently.

Findings Summary (ordered by severity, highest first)

1. [Minor] peerDependencies bumped to 6.6.1 while devDependencies (and lockfile) stay at 6.6.0, and the entry now diverges from the sibling PatternFly peers - Consistency (L25, L37)

Convention Checklist

Convention	Result
Image/dependency references consistent across the stack	Fail
Conventional commit message	Pass

[jsell-rh]

[Minor] Peer/dev version drift. This bumps the peerDependencies pin to 6.6.1, but devDependencies (L37) and the lockfile still resolve @patternfly/react-icons@6.6.0. With exact pins, the package now declares a peer requirement for a version it never builds/tests against, and it diverges from the sibling PatternFly peers (react-core, react-table still 6.6.0). Please bump the devDependencies entry to 6.6.1 too (and regenerate pnpm-lock.yaml) to keep them consistent. Patch bump, so low functional risk.