Skip to content

chore(deps): update javascript#513

Open
renovate[bot] wants to merge 1 commit intomainfrom
renovate/js
Open

chore(deps): update javascript#513
renovate[bot] wants to merge 1 commit intomainfrom
renovate/js

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate bot commented Mar 27, 2026

This PR contains the following updates:

Package Change Age Confidence
@tanstack/react-query (source) 5.95.25.96.2 age confidence
@types/node (source) 24.12.024.12.2 age confidence
eslint (source) 10.1.010.2.0 age confidence
lucide-react (source) 1.6.01.7.0 age confidence
react-hook-form (source) 7.72.07.72.1 age confidence
react-resizable-panels (source) 4.7.54.9.0 age confidence
react-router-dom (source) 7.13.27.14.0 age confidence
recharts 3.8.03.8.1 age confidence
typescript-eslint (source) 8.57.28.58.0 age confidence
vite (source) 8.0.28.0.3 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


Release Notes

TanStack/query (@​tanstack/react-query)

v5.96.2

Compare Source

Patch Changes

v5.96.1

Compare Source

Patch Changes

v5.96.0

Compare Source

Patch Changes
eslint/eslint (eslint)

v10.2.0

Compare Source

Features

Bug Fixes

Documentation

  • a2af743 docs: add language to configuration objects (#​20712) (Francesco Trotta)
  • 845f23f docs: Update README (GitHub Actions Bot)
  • 5fbcf59 docs: remove sourceType from ts playground link (#​20477) (Tanuj Kanti)
  • 8702a47 docs: Update README (GitHub Actions Bot)
  • ddeaded docs: Update README (GitHub Actions Bot)
  • 2b44966 docs: add Major Releases section to Manage Releases (#​20269) (Milos Djermanovic)
  • eab65c7 docs: update eslint versions in examples (#​20664) (루밀LuMir)
  • 3e4a299 docs: update ESM Dependencies policies with note for own-usage packages (#​20660) (Milos Djermanovic)

Chores

  • 8120e30 refactor: extract no unmodified loop condition (#​20679) (kuldeep kumar)
  • 46e8469 chore: update dependency markdownlint-cli2 to ^0.22.0 (#​20697) (renovate[bot])
  • 01ed3aa test: add unit tests for unicode utilities (#​20622) (Manish chaudhary)
  • 811f493 ci: remove --legacy-peer-deps from types integration tests (#​20667) (Milos Djermanovic)
  • 6b86fcf chore: update dependency npm-run-all2 to v8 (#​20663) (renovate[bot])
  • 632c4f8 chore: add prettier update commit to .git-blame-ignore-revs (#​20662) (루밀LuMir)
  • b0b0f21 chore: update dependency eslint-plugin-regexp to ^3.1.0 (#​20659) (Milos Djermanovic)
  • 228a2dd chore: update dependency eslint-plugin-eslint-plugin to ^7.3.2 (#​20661) (Milos Djermanovic)
  • 3ab4d7e test: Add tests for eslintrc-style keys (#​20645) (kuldeep kumar)
lucide-icons/lucide (lucide-react)

v1.7.0: Version 1.7.0

Compare Source

What's Changed

New Contributors

Full Changelog: lucide-icons/lucide@1.6.0...1.7.0

react-hook-form/react-hook-form (react-hook-form)

v7.72.1: Version 7.72.1

Compare Source

🐞 test: add isDirty check for numeric string keys in defaultValues (issue #​13346) (#​13347)
🐞 fix: prevent setValue with shouldDirty from polluting unrelated dirty fields (#​13326)
🐞 fix: memoize control in HookFormControlContext to prevent render conflicts (#​13272) (#​13312)
🐞 fix: isNameInFieldArray should check all ancestor paths for nested field arrays (#​13318)
🐞 fix: #​13320 formState.isValid incorrect on Controller re-mount (#​13324)

thanks to @​6810779s, @​candymask0712, @​olagokemills, @​shahmir-oscilar & @​bae080311

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

v4.9.0

Compare Source

  • 702: Add disableDoubleClick prop to Separator to enable turning off the double-click size reset behavior.

v4.8.0

Compare Source

  • 699: useDefaultLayout hook automatically migrates legacy layouts to version 4 format; see issue 605 for details on how this works.

v4.7.6

Compare Source

  • 698: Replace Panel aria-disabled attribute with data-disabled
remix-run/react-router (react-router-dom)

v7.14.0

Compare Source

Patch Changes
  • Updated dependencies:
    • react-router@7.14.0
recharts/recharts (recharts)

v3.8.1

Compare Source

What's Changed

Bugfixes!

New Contributors

Full Changelog: recharts/recharts@v3.8.0...v3.8.1

typescript-eslint/typescript-eslint (typescript-eslint)

v8.58.0

Compare Source

🚀 Features
❤️ Thank You

See GitHub Releases for more information.

You can read about our versioning strategy and releases on our website.

vitejs/vite (vite)

v8.0.3

Compare Source

Features
Bug Fixes
  • html: cache unfiltered CSS list to prevent missing styles across entries (#​22017) (5464190)
  • module-runner: handle non-ascii characters in base64 sourcemaps (#​21985) (77c95bf)
  • module-runner: skip re-import if the runner is closed (#​22020) (ee2c2cd)
  • optimizer: scan is not resolving sub path import if used in a glob import (#​22018) (ddfe20d)
  • ssr: ssrTransform incorrectly rewrites meta identifier inside import.meta when a binding named meta exists (#​22019) (cff5f0c)
Miscellaneous Chores
Tests

Configuration

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

🚦 Automerge: Enabled.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


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

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

@renovate renovate bot added dependencies Renovatebot and dependabot updates frontend javascript Pull requests that update javascript code labels Mar 27, 2026
@renovate renovate bot enabled auto-merge (squash) March 27, 2026 00:52
@renovate renovate bot added the frontend label Mar 27, 2026
@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 27, 2026

Open in Overmind ↗


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

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ Multiple compute and messaging resources are showing unusual, infrequent change patterns that may need review, with instance resources at 1 event/week for the last 2-3 months and the notification subscription at 2 events/week for the last 3 months.
Policies 🔴 ▃▂▁ Multiple infrastructure resources showing unusual policy violations that may need review: an S3 bucket is missing required tags and does not have server-side encryption configured, while a security group allows SSH (port 22) access from anywhere (0.0.0.0/0).

View signals ↗


🔥 Risks

Publicly reachable EC2 instance has SSH open to the entire internet ‼️High Open Risk ↗
The EC2 instance 540044833068.eu-west-2.ec2-instance.i-0ef4bfdd45730e71d is attached to the shared security group sg-0437857de45b640ce (internet-access), which allows inbound TCP 22 from 0.0.0.0/0. The instance also has a live public IP (13.40.27.201) and public DNS name, so this is not just a theoretical misconfiguration inside a private network: the host is directly reachable for SSH from the internet.

This violates internal policy and AWS hardening guidance and creates a direct path for brute-force and credential-based attacks against the instance. If the host is compromised, an attacker can gain shell access, read data on the attached EBS volume, alter the application or system configuration, and use the instance as a foothold inside the VPC. The current change does not remediate the exposure; it only recomputes the public IP/DNS values, so the insecure access remains in place after deployment.


🧠 Reasoning · ✔ 1 · ✖ 4

Wide-open SSH access on EC2 security group

Observations 1

Hypothesis

The EC2 instance is associated with security group 'internet-access' that allows inbound SSH (port 22) from 0.0.0.0/0. This violates compute hardening guidance (aws-compute-configuration SEC06-BP03) by exposing SSH to the entire internet, significantly increasing brute-force, credential stuffing, and targeted compromise risk. An attacker gaining SSH access could take control of the instance, access data on attached volumes, pivot inside the VPC, or modify application and system configuration. SSH access should be restricted to specific administrative IP ranges, bastion hosts, or VPN endpoints and paired with strong authentication and monitoring.

Investigation

I treated the concern area as security exposure and possible host compromise of the EC2 instance. I first checked relevant organizational knowledge and found explicit internal policy that EC2 instances must not be directly reachable from the internet, that SSH on port 22 must never be open to 0.0.0.0/0, and that having both a public IP and an open security group is critical severity. The compute hardening guidance also explicitly says to flag security groups allowing SSH from 0.0.0.0/0 as a High risk, and network security guidance independently classifies unrestricted SSH ingress as High.

I then verified the actual current configuration in blast radius rather than relying on the hypothesis text. The internet-access security group sg-0437857de45b640ce has an inbound TCP 22 rule from 0.0.0.0/0, and the affected EC2 instance i-0ef4bfdd45730e71d is attached to that same security group and currently has public IP 13.40.27.201 and public DNS ec2-13-40-27-201.eu-west-2.compute.amazonaws.com. The subnet itself is configured with MapPublicIpOnLaunch=false, so the public IP is not merely hypothetical subnet behavior; this instance already has direct internet reachability. I also checked whether the planned change fixes or changes the exposure. It does not: the only diff shown is that public_ip and public_dns become (known after apply), which is normal replacement/computed behavior and does not remove the public endpoint or the permissive security group rule. There is no planned change to the security group, no evidence of Session Manager replacing SSH, and no IAM instance profile attached to this instance to support an argument that SSM access is being used instead. AWS documentation also supports the conclusion that unrestricted ingress from 0.0.0.0/0 on SSH is a security risk and recommends Session Manager instead of direct SSH.

Because the insecure exposure already exists on the changed instance and the current change leaves that exposure in place while updating the instance, this is a real risk in the concern area raised by the hypothesis. The risk is not an apply-time validation failure; it is an operational security exposure with potential host compromise impact, so High is appropriate.

✔ Hypothesis proven


Opaque EC2 compute configuration changes (AMI/sizing/hardening)

Observations 1

Hypothesis

Updates to EC2 instances with empty or incomplete diffs can mask changes to foundational compute configuration such as AMI/hardening level, instance type/sizing, attached instance profile, and security posture. If AMIs are changed without tracking hardening/patch status, instances may run unpatched or non-compliant images; if instance type or related capacity settings change without review, workloads may be under- or over-provisioned, impacting performance, stability, and cost. Change procedures should enforce explicit recording and review of AMI, instance type, and core compute attributes for any EC2 update with special attention to compliance baselines and sizing requirements.

Investigation

I investigated the concern area as potential hidden EC2 compute changes affecting AMI, sizing, hardening, or security posture on the updated instances. I first checked the relevant organizational knowledge. The compute guidance says to flag concrete risks such as old or unpatched AMIs, missing IAM instance profiles, poor hardening, or problematic sizing changes; the security policy also says EC2 instances must not have public IPs. I then examined the full planned diffs for all EC2 instances in this change, including the Terraform module resources. The only explicit change on the affected instances is that public_ip and public_dns become (known after apply). There are no diff entries showing ami, instance_type, iam_instance_profile, metadata_options, security group attachment, block device encryption, or other foundational compute attributes changing. The module-level resources also have empty diffs, which is consistent with no material attribute changes being exposed here rather than evidence of a hidden AMI or sizing change.

I checked current state in the blast radius to see whether there was a concrete existing problem that this change would worsen. The main API instance 540044833068.eu-west-2.ec2-instance.i-08c49ffb6f2242b1e is currently c5.large on AMI ami-0dd010f28b091c0fd, has an IAM instance profile attached, is healthy in the target group, and is only reachable on port 80 from the ALB security group. That means the hypothesis about hidden hardening, sizing, or instance-profile drift is not supported by the evidence in this change. I also found an unrelated current-state compliance issue: these instances are in a public subnet and have public IPv4 addresses, which conflicts with the organization’s security requirement that EC2 instances must not be directly reachable from the internet. But this change does not introduce that condition; it only reflects Terraform recomputing public IP/DNS values after apply. AWS documentation confirms automatically assigned public IPv4 addresses and public DNS names are provider-assigned values that commonly change after stop/start or replacement, and Terraform marks them as (known after apply) until AWS returns the new values. Because there is no evidence that AMI, instance type, hardening, or core compute configuration is actually changing here, the specific concern area raised by the hypothesis is not a real risk for this change.

✖ Hypothesis disproven


EBS DeleteOnTermination configuration causing data loss risk

Observations 1

Hypothesis

EBS volume vol-0e86199cac82f2256 is attached to instance i-0ef4bfdd45730e71d with DeleteOnTermination:true. Any change that terminates or replaces this instance (including updates that recreate the instance) will automatically delete the attached volume, causing irreversible data loss if the volume holds stateful data. This contravenes compute configuration best practices for persistence and backups (aws-compute-configuration SEC6/PERF2) where important data should be on non-ephemeral volumes or protected by snapshots/backup policies. Before applying such changes, validate that critical data is backed up or that the volume is intended to be ephemeral.

Investigation

I investigated the concern area of stateful data loss on 540044833068.eu-west-2.ec2-volume-status.vol-0e86199cac82f2256 if the attached EC2 instance were terminated or replaced. I first checked the relevant organizational knowledge. The guidance does say that important data should not rely on ephemeral instance storage patterns and that critical EBS data should have automated backup/snapshot protection. I then examined the actual planned change and current state.

The current instance 540044833068.eu-west-2.ec2-instance.i-0ef4bfdd45730e71d does have a single attached EBS root volume 540044833068.eu-west-2.ec2-volume.vol-0e86199cac82f2256 with DeleteOnTermination: true, and AWS documentation confirms that such a volume is deleted if the instance is terminated. However, the planned diff for this change does not show any replacement-triggering change to the instance configuration. The only visible change is that public_ip and public_dns become (known after apply), which is a computed-value refresh rather than evidence of instance recreation. The plan marks the resource as updated, not replaced, and no force-new attributes, termination actions, block device changes, or volume lifecycle changes are present in the available diffs. The volume was also created from snapshot snap-0d3bf98f60e01d97a, which weakens the claim of irreversible loss from this specific change because there is at least an existing recoverable source image for the root disk.

So while the hypothesis identifies a real general hazard of this instance design, I found no evidence that this particular Terraform change will terminate or replace the instance and thereby trigger deletion of the root volume. Without a replacement path in the diffs, the concern remains speculative for this change rather than a concrete risk caused by it.

✖ Hypothesis disproven


EC2 instance lifecycle impacting IP-backed DNS endpoints

Observations 1

Hypothesis

Changes to EC2 instance i-0ef4bfdd45730e71d can alter availability or IP assignment for private IP 10.0.101.211, potentially invalidating the DNS hostname ip-10-0-101-211.eu-west-2.compute.internal that resolves to that IP. Instance replacement, stop/start cycles, or ENI reattachment may change or detach this IP, breaking clients and services that depend on the IP-backed hostname instead of a stable endpoint. This creates fragility in service discovery and violates resilience guidance (AWS Well-Architected REL02-BP01). Workloads should use stable service discovery mechanisms (load balancers, Route 53 records, or logical service names) rather than individual instance IPs/DNS names.

Investigation

I investigated the concern area as service discovery fragility around the private DNS name ip-10-0-101-211.eu-west-2.compute.internal for EC2 instance 540044833068.eu-west-2.ec2-instance.i-0ef4bfdd45730e71d. I first checked relevant organizational guidance: aws-high-availability, aws-compute-configuration, and infrastructure-quick-reference. The reliability guidance does favor resilient service discovery, but it does not make every EC2 private DNS record change a concrete risk; I still needed evidence that this change actually alters the private endpoint.

The planned diff for the instance shows only public_ip and public_dns becoming (known after apply). There is no diff for private_ip, hostname type, subnet, ENI, or the private DNS name. Current blast-radius state confirms the instance’s primary ENI carries private IP 10.0.101.211 and private DNS ip-10-0-101-211.eu-west-2.compute.internal. AWS documentation says a stopped/started EC2 instance retains its attached network interfaces and private IPv4 addresses, while automatically assigned public IPv4 addresses can change. AWS also documents that an IP-name private DNS name resolves to the instance’s private IPv4 address. That means this change is evidencing expected recomputation of the ephemeral public endpoint, not a planned change to the private IP-backed DNS name. I found no evidence of instance replacement, ENI reassignment, or private IP modification in the diffs, so the specific concern area is not supported for this change.

✖ Hypothesis disproven


EC2 instance profile association changes breaking role-based access

Observations 1

Hypothesis

EC2 instance i-08c49ffb6f2242b1e is associated with IAM instance profile 'api-207c90ee-api-profile' (role 'api-207c90ee-api-role'). An instance update with no recorded diff may still change or remove its IAM instance profile association. If the profile is replaced or detached, applications and agents on the instance can lose assumed-role credentials required to access AWS APIs such as S3, SSM, and CloudWatch. This can cause sudden failures in application functionality, observability, automation, and management, and may also introduce least-privilege violations if replaced with an overly broad role. Change control for EC2 updates must verify and explicitly track instance profile associations and their permissions in line with aws-iam-access-control best practices. Severity: Medium.

Investigation

I investigated the concern area of role-based access loss on EC2 due to an instance profile association change. Per organizational guidance, I first checked the relevant knowledge files for IAM/access control and EC2 hardening. Those standards do say missing or improperly changed instance profiles are a real risk, so the hypothesis was worth validating.

The actual planned diff for 540044833068.eu-west-2.ec2-instance.i-08c49ffb6f2242b1e shows only public_dns and public_ip changing from concrete values to (known after apply). There is no planned change to iam_instance_profile, no diff on the instance profile resource, and no diff on the module resources backing this instance. The current blast-radius state confirms the instance is associated with IAM instance profile api-207c90ee-api-profile, which contains role api-207c90ee-api-role, and the EC2 IAM instance profile association resource is currently in associated state.

I also checked AWS documentation on EC2 instance profiles and instance profile replacement semantics. AWS documents that changing an instance profile association is an explicit operation (ReplaceIamInstanceProfileAssociation / replacing the instance profile), not something implied by an unrelated public IP recomputation. AWS also warns that removing a role from an instance profile can break applications, but there is no evidence of any such IAM/profile modification in this plan. In this change, the only visible effect is that Terraform cannot know the future public IP/DNS until apply, which is a normal computed-value behavior for EC2 and does not by itself imply IAM association drift.

Because the hypothesis depends on an unshown IAM/profile change that is not present in the diffs or related planned resources, and the available evidence shows the current profile association remains intact, I found no concrete support for the claimed failure mode or a closely related IAM-access failure in this change.

✖ Hypothesis disproven


💥 Blast Radius

Items 16

Edges 45

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ Auto-Blocked


🔴 Decision

Auto-blocked: Routine score (-5) is below minimum (-1)


📊 Signals Summary

Routine 🔴 -5


🔥 Risks Summary

High 0 · Medium 0 · Low 0


💥 Blast Radius

Items 97 · Edges 246


View full analysis in Overmind ↗

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ 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 27 · Edges 66


View full analysis in Overmind ↗

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ 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 8 · Edges 30


View full analysis in Overmind ↗

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ Auto-Blocked


🔴 Decision

Found 2 high risks requiring review


📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3


🔥 Risks Summary

High 2 · Medium 0 · Low 0


💥 Blast Radius

Items 11 · Edges 25


View full analysis in Overmind ↗

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ 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 8 · Edges 30


View full analysis in Overmind ↗

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ 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 12 · Edges 38


View full analysis in Overmind ↗

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ 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 4 · Edges 20


View full analysis in Overmind ↗

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ Auto-Blocked


🔴 Decision

Found 1 high risk requiring review


📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3


🔥 Risks Summary

High 1 · Medium 0 · Low 0


💥 Blast Radius

Items 2 · Edges 20


View full analysis in Overmind ↗

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overmind

⛔ Auto-Blocked


🔴 Decision

Found 1 high risk requiring review


📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3


🔥 Risks Summary

High 1 · Medium 0 · Low 0


💥 Blast Radius

Items 16 · Edges 45


View full analysis in Overmind ↗

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Renovatebot and dependabot updates frontend javascript Pull requests that update javascript code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants