fix(deps): update dependency react-resizable-panels to v4

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
react-resizable-panels (source)	^2.1.9 → ^4.0.0

---

Release Notes

bvaughn/react-resizable-panels (react-resizable-panels)

v4.6.5

Compare Source

• 670: Check for undefined adoptedStyleSheets (to better support environments like jsdom)
• 671: Bug-fix: Update in-memory layout cache when group is resized by double-clicking on a separator

v4.6.4

Compare Source

• 664, 665: Resize actions sometimes "jump" on touch devices

v4.6.3

Compare Source

• Fixed a problem with project logo not displaying correctly in the README for the Firefox browser.

v4.6.2

Compare Source

• 660: Group guards against layouts with mis-ordered Panel id keys

v4.6.1

Compare Source

• 658: Imperative Panel and Group APIs ignored disabled status when resizing panels; this is an explicit override of the disabled state and is required to support conditionally disabled groups.
• 658: Separator component does not set a cursor: not-allowed style if the parent Group has cursors disabled.

v4.6.0

Compare Source

• 657: Allow Panel and Separator components to be disabled

v4.5.9

Compare Source

• 649: Optimization: Replace useForceUpdate with useSyncExternalStore to avoid side effect of swallowing "click" events in certain cases
• 654: Bugfix Imperative Group method setLayout persists layout to in-memory cache
• 652: Re-enable collapsible panel bugfix after fixing another reported issue

v4.5.8

Compare Source

• 651: Disabled the change to collapsible panel behavior that was originally made in 635 due to another reported regression

v4.5.7

Compare Source

• 646: Re-enable the collapsible Panel from 4.5.3 that was disabled in 4.5.6
• 648: Bugfix: Reset Separator hover-state on Document "pointerout"

v4.5.6

Compare Source

• 644: Disabled the change to collapsible panel behavior that was originally made in 635

v4.5.5

Compare Source

• 641: Removed aria-orientation role from root Group element as this was invalid according to the ARIA spec; (for more information see the discussion on issue #​640)
• 642: Bugfix: Fix collapsible Panel regression introduced in 4.5.3

v4.5.4

Compare Source

• 638: Panel avoids unnecessary re-renders in response to mouse-hover state.

v4.5.3

Compare Source

• 635: Expand pre-collapsed panels if drug past the halfway point for more consistent collapse/expand behavior.
• 631: Bugfix: Panels set max-width and max-height to 100% to fix potential CSS overflow bug.

v4.5.2

Compare Source

• 626: Decrease default hit target size for Separator and Panel edges; make configurable via a new Group prop.

v4.5.1

Compare Source

• 624: Bugfix: Fallback to alternate CSS cursor styles for Safari

Safari	Chrome, Firefox
grab	move
col-resize	ew-resize
row-resize	ns-resize

v4.5.0

Compare Source

• 616: Replace Separator and Panel edge hit-area padding with a minimum size threshold based on Apple's user interface guidelines. Separators that are large enough will no longer be padded; separators that are too small (or panels without separators) will more or less function like before. This should not have much of a user-facing impact other than an increase in the click target area. (Previously I was not padding enough, as per Apple's guidelines.)
• 615, 620: Double-clicking on a Separator resets its associated Panel to its default-size (see video below); double-click will have no impact on panels without default sizes
• 622: Bugfix: Panels within vertical groups are now properly sized in Safari
• 618: Bugfix: Don't override adoptedStyleSheets

Demo of double-clicking on a separator:

dbl-click.mov

v4.4.2

Compare Source

• 610: Fix calculated cursor style when "pointermove" event is has low-precision/rounded clientX and clientY values

v4.4.1

Compare Source

• 600: Bugfix: Collapsible Panel should treat defaultSize={0} as collapsed on mount

v4.4.0

Compare Source

• 599: Add new onLayoutChanged prop to Group.

For layout changes caused by pointer events, this method is not called until the pointer has been released. This callback should be used if you're doing something like saving a layout as it is called less frequently than the previous approach.

The useDefaultLayout hook has also been updated to use this callback (though it will continue to support the old callback as well, with a @deprecation tag).

v4.3.3

Compare Source

• 595: Don't call event.preventDefault() on "pointerup" unless a handle was actively dragged

[!NOTE]
This change also fixes a text selection bug that impacted Windows users (#​574)

v4.3.2

Compare Source

• Moved flex-grow Panel style to an inline value instead of a CSS variable defined on the parent Group to improve rendering performance. (This significantly reduces the negative impact from forced-reflow)

v4.3.1

Compare Source

• 588: Replace "unset" styles with safer override values
• 589: Use capture phase for "pointerdown" and "pointerup" events; this is necessary for compatibility with certain UI libraries like Blueprint JS
• 590: Read Panel pixel size using offsetWidth/offsetHeight rather than inlineSize to avoid an edgecase bug with ResizeObserver

v4.3.0

Compare Source

• 583: Group component now sets default width, height, and overflow styles; (both can be overridden using the style property)
• 582: Drag interactions only call event.preventDefault for the primary button
• Refine TS types for useGroupRef and usePanelRef to include | null to increase compatibility with older React versions
• Update TSDoc comments for Panel and Separator components

v4.2.2

Compare Source

• useDefaultLayout hook initializes storage param to localStorage if undefined.
• Fix ambiguous type for Panel prop onResize that impacted certain TypeScript versions.

v4.2.1

Compare Source

• 2a6b03f: Add displayName property to Group, Panel, and Separator components for better debugging experience.
• 577: Group handles newly registered Panels + Separators during mount so that user code can safely call imperative APIs earlier

v4.2.0

Compare Source

• 573: Add prevPanelSize param to onResize callback to help simplify collapse/expand detection.

v4.1.1

Compare Source

• 571: Update TS types to better reflect that Separator attributes role and tabIndex cannot be overridden using props.

v4.1.0

Compare Source

• 567: useDefaultLayout hook supports saving and restoring multiple Panel layouts
• 568: Fix race in useGroupRef and usePanelRef hooks

v4.0.16

Compare Source

• 563: Panel expand() API should restore pre-collapse size
• 564: Add guard for unexpected defaultView value seemingly returned by some dev environments

v4.0.15

Compare Source

• 556: Ignore defaultLayout when keys don't match Panel ids

v4.0.14

Compare Source

• 555: Allow resizable panels to be rendered into a different Window (e.g. popup or frame) by accessing globals through element.ownerDocument.defaultView

v4.0.13

Compare Source

• useDefaultLayout: Deprecated groupId param in favor of id to avoid confusion; (there is no actual requirement for the Group to have a matching id)

v4.0.12

Compare Source

• 552: useDefaultLayout now debounces calls to storage.setItem by 150ms

// To opt out of this change
useDefaultLayout({
  debounceSaveMs: 0,
  groupId: "test-group-id",
  storage: localStorage,
})

[!NOTE]
Some may consider this a breaking change, considering the default value is 150ms rather than 0ms. I think in practice this should only impact unit tests which can be easily fixed by overriding the default (as shown above) or by using fake timers.

Changes like this are often judgement calls, but I think on balance it's better to correct my initial oversight of not debouncing this by default.

v4.0.11

Compare Source

• 8604491: Fix edge case bug with panel constraints not being properly invalidated after resize

v4.0.10

Compare Source

• #​551: Expand fixed-size element support

v4.0.9

Compare Source

• #​542: Clicks on higher z-index elements (e.g. modals) should not trigger separators behind them
• #​547: Don't re-mount Group when defaultLayout or disableCursor props change
• #​548: Bugfix: Gracefully handle Panel id changes
• #​549: Improve DevX when Group within hidden DOM subtree; defer layout-change events

v4.0.8

Compare Source

• #​541: Don't set invalid layouts when Group is hidden or has a width/height of 0
• 40d4356: Gracefully handle invalid defaultLayout value

v4.0.7

Compare Source

• f07bf00: Reset pointer-event styles after "pointerup" event

v4.0.6

Compare Source

• 0796644: Account for Flex gap when calculating pointer-move delta %

v4.0.5

Compare Source

• #​535: Updated docs to make size and layout formats clearer

v4.0.4

Compare Source

• #​534: Set focus on Separator on "pointerdown"
• e08fe42: Improve iOS/Safari resize UX

v4.0.3

Compare Source

• Fixed TS type for defaultLayout value returned from useDefaultLayout

v4.0.2

Compare Source

• Export GroupImperativeHandle and PanelImperativeHandle types.

v4.0.1

Compare Source

• useDefaultLayout: Deprecated groupId param in favor of id to avoid confusion; (there is no actual requirement for the Group to have a matching id)

v4.0.0

Compare Source

Version 4 of react-resizable-panels offers more flexible size constraints– supporting units as pixels, percentages, REMs/EMs, and more. Support for server-rendering (including Server Components) has also been expanded.

Migrating from version 3 to 4

Refer to the docs for a complete list of props and API methods. Below are some examples of migrating from version 3 to 4, but first a couple of potential questions:

Q: Why'd you rename <component> or <prop>?

A: The most likely reason is that I think the new name more closely aligns with web standards like WAI-ARIA and CSS. For example, the PanelResizeHandle component was renamed to Separator to better align with the ARIA "separator" role and the direction prop was renamed to orientation to better align with the ARIA orientation attribute .

Q: Why'd you remove support for <feature>?

A: Probably because it wasn't used widely enough to justify the complexity required to maintain it. If it turns out that I'm mistaken, features can always be (re)added but it's more difficult to remove them.

Q: Were the onCollapse and onExpand event handlers removed?

A: Yes. Use the onResize event handler instead:

onResize={(size) => {
  // Either this
  const isCollapsed = size === collapsedSize;

  // Or this:
  panelRef.isCollapsed();
}}

Basic usage example

// Version 3

import { PanelGroup, Panel, PanelResizeHandle } from "react-resizable-panels";

<PanelGroup direction="horizontal">
  <Panel defaultSize={30} minSize={20}>left</Panel>
  <PanelResizeHandle />
  <Panel defaultSize={30} minSize={20}>right</Panel>
</PanelGroup>

// Version 4

import { Group, Panel, Separator } from "react-resizable-panels";

<Group orientation="horizontal">
  <Panel defaultSize="30%" minSize="20%">left</Panel>
  <Separator />
  <Panel defaultSize="30%" minSize="20%">right</Panel>
</Group>

Persistent layouts using localStorage

// Version 3

import { PanelGroup, Panel, PanelResizeHandle } from "react-resizable-panels";

<PanelGroup autoSaveId="unique-group-id" direction="horizontal">
  <Panel>left</Panel>
  <PanelResizeHandle />
  <Panel>right</Panel>
</PanelGroup>

// Version 4

import { Group, Panel, Separator, useDefaultLayout } from "react-resizable-panels";

const { defaultLayout, onLayoutChange } = useDefaultLayout({
  groupId: "unique-group-id",
  storage: localStorage
});

<Group defaultLayout={defaultLayout} onLayoutChange={onLayoutChange}>
  <Panel>left</Panel>
  <Separator />
  <Panel>right</Panel>
</Group>

[!NOTE]
Refer to the docs for examples of persistent layouts with server rendering and server components.

Conditional panels

// Version 3

import { PanelGroup, Panel, PanelResizeHandle } from "react-resizable-panels";

<PanelGroup autoSaveId="unique-group-id" direction="horizontal">
   {showLeftPanel && (
     <>
       <Panel id="left" order={1}>left</Panel>
       <PanelResizeHandle />
     </>
   )}
   <Panel id="center" order={2}>center</Panel>
   {showRightPanel && (
     <>
       <PanelResizeHandle />
       <Panel id="right" order={3}>right</Panel>
     </>
   )}
</PanelGroup>

// Version 4

import { Group, Panel, Separator } from "react-resizable-panels";

<Group>
  {showLeftPanel && (
    <>
      <Panel id="left">left</Panel>
      <Separator />
    </>
  )}
  <Panel id="center">center</Panel>
  {showRightPanel && (
    <>
      <Separator />
      <Panel id="right">right</Panel>
    </>
  )}
</Group>

Imperative APIs

// Version 3

import { PanelGroup, Panel, PanelResizeHandle } from "react-resizable-panels";
import type { ImperativePanelGroupHandle, ImperativePanelHandle }from "react-resizable-panels";

 const panelRef = useRef<ImperativePanelHandle>(null);
 const panelGroupRef = useRef<ImperativePanelGroupHandle>(null);

<PanelGroup direction="horizontal" ref={panelGroupRef}>
  <Panel ref={panelRef}>left</Panel>
  <PanelResizeHandle />
  <Panel>right</Panel>
</PanelGroup>

// Version 4

import { Group, Panel, Separator, useGroupRef, usePanelRef } from "react-resizable-panels";

const groupRef = useGroupRef();
const panelRef = usePanelRef();

<Group groupRef={groupRef} orientation="horizontal">
  <Panel panelRef={panelRef}>left</Panel>
  <Separator />
  <Panel>right</Panel>
</Group>

Disabling custom cursors

// Version 3

import { disableGlobalCursorStyles } from "react-resizable-panels";

disableGlobalCursorStyles();

// Version 4

import { Group, Panel, Separator } from "react-resizable-panels";

<Group disableCursor />

v3.0.6

Compare Source

• #​517: Fixed Firefox bug that caused resizing to be interrupted unexpected

v3.0.5

Compare Source

• #​512: Fixed size precision regression from 2.0.17

v3.0.4

Compare Source

• #​503: Support custom cursors

v3.0.3

Compare Source

• #​492: Fix compatibility with Cloudflare workers

v3.0.2

Compare Source

• Fallback for type of HTMLElement to better support portal edge cases

v3.0.1

Compare Source

• #​479: Improve support for Cloudflare Workers and Vercel Functions
• #​480: Fixed package.json#types reference

v3.0.0

Compare Source

• #​478: Module is ESM-only in order to better work with modern tooling.
• #​475: "pointerup" and "pointercancel" listeners are now attached to the ownerDocument body to better support edge cases like portals being rendered into a child window.

---

Configuration

📅 Schedule: Branch creation - "before 10am on friday" in timezone Europe/London, Automerge - At any time (no schedule defined).

🚦 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.

---

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

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Open in Overmind ↗

---

model|risks_v6
✨Encryption Key State Risk ✨KMS Key Creation

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ SNS topic subscription (module.api_access[0].aws_sns_topic_subscription.oncall_email) showing only 2 events/week for the last 3 months, which is infrequent compared to typical patterns.
Policies 🔴 ▃▂▁ S3 bucket showing no server-side encryption configured and a security group allowing SSH (port 22) access from anywhere (0.0.0.0/0), which is unusual compared to typical patterns and may need review.

View signals ↗

---

🔥 Risks

Email SNS subscription requires manual confirmation; topic currently has 0 confirmed subscribers so alerts will not be delivered until confirmed ❗Medium Open Risk ↗
The change adds an email subscription (alerts@example.com, protocol email) to the shared production-api-alerts SNS topic, but email subscriptions require manual confirmation and endpoint_auto_confirms=false with only confirmation_timeout_in_minutes=1. The topic currently has zero confirmed subscribers and one pending subscription, so this new path will not deliver notifications until someone confirms the email.

Until confirmation occurs, alarms publishing to production-api-alerts will have no effective human notification target, delaying incident detection and acknowledgment. This degrades reliability and violates monitoring best practices for working alarm notifications (REL06-BP03, REL11-BP01).

---

🧠 Reasoning · ✔ 1 · ✖ 1

Unvalidated email alert channel and misaligned escalation process

Observations 2

Hypothesis

Adding the email subscription module.api_access[0].aws_sns_topic_subscription.oncall_email (protocol email, endpoint alerts@example.com) to the shared production-api-alerts SNS topic introduces an unvalidated human-notification path. If the mailbox is unconfirmed, filtered, misconfigured, or not monitored 24/7, alarms sent via this subscription may not be seen in time, weakening incident detection and recovery (REL06-BP03, REL11-BP01). In addition, routing incidents to an email mailbox without aligning runbooks, escalation paths, or ownership may cause alert fatigue, unclear responsibility, or delayed acknowledgment if this address is treated as a duplicate or replacement for existing paging mechanisms (OPS04-BP02, REL11-BP01, engineering-change-process). Overall, the monitoring topology is changing faster than the documented human response process, creating a reliability and operational-process risk around who actually responds to production-api-alerts.

Investigation

Evidence Gathered

• Loaded org knowledge: aws-monitoring-detection (REL06-BP03, REL11-BP01 guidance), aws-high-availability (reliability/operations context), engineering-change-process (Event Bus/SNS coordination requirements).
• Planned change diff shows creation of an SNS email subscription: protocol=email, endpoint=alerts@example.com, endpoint_auto_confirms=false, confirmation_timeout_in_minutes=1, topic_arn=arn:aws:sns:eu-west-2:540044833068:production-api-alerts (GUN: github.com/overmindtech/terraform-example.aws_sns_topic_subscription.module.api_access[0].aws_sns_topic_subscription.oncall_email).
• Blast radius query for the topic shows SubscriptionsConfirmed=0, SubscriptionsPending=1, TopicArn=arn:aws:sns:eu-west-2:540044833068:production-api-alerts. This proves the shared topic currently has no confirmed recipients and at least one pending/unconfirmed subscription.

Impact Assessment

• Directly affected resource: 1 shared SNS topic in eu-west-2 used for production API alerts: 540044833068.eu-west-2.sns-topic.arn:aws:sns:eu-west-2:540044833068:production-api-alerts.
• With SubscriptionsConfirmed=0 before the change and the new subscription requiring manual confirmation (email, endpoint_auto_confirms=false), alerts published to this topic will not be delivered until a human clicks the confirmation link. The plan only waits 1 minute for confirmation, so the subscription will almost certainly remain pending immediately after apply.
• Operational consequence: Any CloudWatch alarms or automated notifiers that publish to this topic will have no effective human notification path until the mailbox confirms, delaying incident detection and acknowledgment. This violates AWS Well-Architected guidance to ensure alarms have working notification targets (REL06-BP03) and undermines failure detection (REL11-BP01). Scope is all alerts routed via this shared “production-api-alerts” topic across the production API surface.

Conclusion

Risk is real. Key evidence: the target SNS topic currently has zero confirmed subscribers, and the only planned addition is an email endpoint that requires out-of-band confirmation with a one-minute wait, so alerts will not reach humans until confirmation occurs, weakening incident response.

✔ Hypothesis proven

---

External email subscription expanding alert content exposure

Observations 1

Hypothesis

Subscribing an external email endpoint alerts@example.com to the production-api-alerts SNS topic extends the distribution of operational and security alerts beyond the existing AWS-only path. If these alerts contain sensitive incident details, stack traces, account or tenant identifiers, or remediation instructions, the content may now traverse less-controlled infrastructure (email forwarding, 3rd-party mail providers) and be stored or retained outside approved policies. A compromise of the mailbox or its provider could expose incident data, and email retention/backup may conflict with security and compliance requirements (SEC04-BP01, security-compliance-requirements). This is a security/compliance boundary expansion risk around alert content distribution.

Investigation

Evidence Gathered

• Reviewed organizational knowledge: security-compliance-requirements, aws-iam-access-control, aws-data-protection, and aws-monitoring-detection. None define a control that forbids sending alerts to external email addresses; the SEC04-BP01 reference in our standards pertains to CloudTrail/detective controls, not SNS/email distribution.
• Planned changes show a new SNS email subscription to endpoint alerts@example.com on topic arn:aws:sns:eu-west-2:540044833068:production-api-alerts with protocol: email, endpoint_auto_confirms: false, and confirmation_timeout_in_minutes: 1 (resource: github.com/overmindtech/terraform-example.aws_sns_topic_subscription.module.api_access[0].aws_sns_topic_subscription.oncall_email).
• Blast radius for the topic shows SubscriptionsPending: 1, SubscriptionsConfirmed: 0. This indicates the email subscription is not confirmed; SNS does not deliver messages to unconfirmed email subscriptions. The topic policy only allows actions from the owning account (condition AWS:SourceOwner: 540044833068), which does not change distribution scope by itself.

Impact Assessment

• Directly affected resource count: 1 SNS topic (production-api-alerts) and 1 proposed subscription endpoint. No other downstream resources are altered by this change.
• While confirmed external subscriptions could expand where alert contents are stored, there is no evidence that: (a) the subscription will be confirmed, (b) the alerts include sensitive content that violates policy, or (c) our standards prohibit external alert recipients. With the subscription currently pending, zero alerts would be delivered externally, so no data exposure occurs at deployment time.
• Scope of disruption if applied as-is: none; message delivery path to existing subscribers remains unchanged. If the email were later confirmed, risk would depend on alert content classification and provider controls, which is outside the immediate change.

Conclusion

Not a real risk for this deployment. The change only creates an unconfirmed SNS email subscription; SNS will not deliver alerts until explicit confirmation occurs, and our documented standards do not prohibit external recipients. The hypothesized security/compliance exposure is speculative and contingent on post-deploy actions and alert content, not supported by current evidence.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 0

Edges 0

[github-actions]

✅ Auto-Approved

---

🟢 Decision

Auto-approved: All safety checks passed

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2)

---

📊 Signals Summary

Policies 🔴 -3

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2)

---

📊 Signals Summary

Policies 🔴 -3

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2); Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

💥 Blast Radius

Items 1 · Edges 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2); Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Found 2 high risks requiring review

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 2 · Medium 1 · Low 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2); Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 0 · Medium 1 · Low 0

---

View full analysis in Overmind ↗