chore(deps): update dependency typescript to v6 - autoclosed

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
typescript (source)	^5.8.3 → ^6.0.0

---

Release Notes

microsoft/TypeScript (typescript)

v6.0.2

Compare Source

---

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.

[renovate]

⚠️ 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: modules/api-server/demo-app/package-lock.json

npm warn Unknown env config "store". This will stop working in the next major version of npm.
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @typescript-eslint/eslint-plugin@8.57.2
npm warn Found: typescript@6.0.2
npm warn node_modules/typescript
npm warn   dev typescript@"^6.0.0" from the root project
npm warn   1 more (ts-api-utils)
npm warn
npm warn Could not resolve dependency:
npm warn peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/eslint-plugin@8.57.2
npm warn node_modules/@typescript-eslint/eslint-plugin
npm warn   @typescript-eslint/eslint-plugin@"8.57.2" from typescript-eslint@8.57.2
npm warn   node_modules/typescript-eslint
npm warn
npm warn Conflicting peer dependency: typescript@5.9.3
npm warn node_modules/typescript
npm warn   peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/eslint-plugin@8.57.2
npm warn   node_modules/@typescript-eslint/eslint-plugin
npm warn     @typescript-eslint/eslint-plugin@"8.57.2" from typescript-eslint@8.57.2
npm warn     node_modules/typescript-eslint
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @typescript-eslint/parser@8.57.2
npm warn Found: typescript@6.0.2
npm warn node_modules/typescript
npm warn   dev typescript@"^6.0.0" from the root project
npm warn   1 more (ts-api-utils)
npm warn
npm warn Could not resolve dependency:
npm warn peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/parser@8.57.2
npm warn node_modules/@typescript-eslint/parser
npm warn   peer @typescript-eslint/parser@"^8.57.2" from @typescript-eslint/eslint-plugin@8.57.2
npm warn   node_modules/@typescript-eslint/eslint-plugin
npm warn   1 more (typescript-eslint)
npm warn
npm warn Conflicting peer dependency: typescript@5.9.3
npm warn node_modules/typescript
npm warn   peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/parser@8.57.2
npm warn   node_modules/@typescript-eslint/parser
npm warn     peer @typescript-eslint/parser@"^8.57.2" from @typescript-eslint/eslint-plugin@8.57.2
npm warn     node_modules/@typescript-eslint/eslint-plugin
npm warn     1 more (typescript-eslint)
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @typescript-eslint/project-service@8.57.2
npm warn Found: typescript@6.0.2
npm warn node_modules/typescript
npm warn   dev typescript@"^6.0.0" from the root project
npm warn   1 more (ts-api-utils)
npm warn
npm warn Could not resolve dependency:
npm warn peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/project-service@8.57.2
npm warn node_modules/@typescript-eslint/project-service
npm warn   @typescript-eslint/project-service@"8.57.2" from @typescript-eslint/typescript-estree@8.57.2
npm warn   node_modules/@typescript-eslint/typescript-estree
npm warn
npm warn Conflicting peer dependency: typescript@5.9.3
npm warn node_modules/typescript
npm warn   peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/project-service@8.57.2
npm warn   node_modules/@typescript-eslint/project-service
npm warn     @typescript-eslint/project-service@"8.57.2" from @typescript-eslint/typescript-estree@8.57.2
npm warn     node_modules/@typescript-eslint/typescript-estree
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @typescript-eslint/tsconfig-utils@8.57.2
npm warn Found: typescript@6.0.2
npm warn node_modules/typescript
npm warn   dev typescript@"^6.0.0" from the root project
npm warn   1 more (ts-api-utils)
npm warn
npm warn Could not resolve dependency:
npm warn peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/tsconfig-utils@8.57.2
npm warn node_modules/@typescript-eslint/tsconfig-utils
npm warn   @typescript-eslint/tsconfig-utils@"^8.57.2" from @typescript-eslint/project-service@8.57.2
npm warn   node_modules/@typescript-eslint/project-service
npm warn   1 more (@typescript-eslint/typescript-estree)
npm warn
npm warn Conflicting peer dependency: typescript@5.9.3
npm warn node_modules/typescript
npm warn   peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/tsconfig-utils@8.57.2
npm warn   node_modules/@typescript-eslint/tsconfig-utils
npm warn     @typescript-eslint/tsconfig-utils@"^8.57.2" from @typescript-eslint/project-service@8.57.2
npm warn     node_modules/@typescript-eslint/project-service
npm warn     1 more (@typescript-eslint/typescript-estree)
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @typescript-eslint/type-utils@8.57.2
npm warn Found: typescript@6.0.2
npm warn node_modules/typescript
npm warn   dev typescript@"^6.0.0" from the root project
npm warn   1 more (ts-api-utils)
npm warn
npm warn Could not resolve dependency:
npm warn peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/type-utils@8.57.2
npm warn node_modules/@typescript-eslint/type-utils
npm warn   @typescript-eslint/type-utils@"8.57.2" from @typescript-eslint/eslint-plugin@8.57.2
npm warn   node_modules/@typescript-eslint/eslint-plugin
npm warn
npm warn Conflicting peer dependency: typescript@5.9.3
npm warn node_modules/typescript
npm warn   peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/type-utils@8.57.2
npm warn   node_modules/@typescript-eslint/type-utils
npm warn     @typescript-eslint/type-utils@"8.57.2" from @typescript-eslint/eslint-plugin@8.57.2
npm warn     node_modules/@typescript-eslint/eslint-plugin
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @typescript-eslint/typescript-estree@8.57.2
npm warn Found: typescript@6.0.2
npm warn node_modules/typescript
npm warn   dev typescript@"^6.0.0" from the root project
npm warn   1 more (ts-api-utils)
npm warn
npm warn Could not resolve dependency:
npm warn peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/typescript-estree@8.57.2
npm warn node_modules/@typescript-eslint/typescript-estree
npm warn   @typescript-eslint/typescript-estree@"8.57.2" from @typescript-eslint/parser@8.57.2
npm warn   node_modules/@typescript-eslint/parser
npm warn   3 more (@typescript-eslint/type-utils, ...)
npm warn
npm warn Conflicting peer dependency: typescript@5.9.3
npm warn node_modules/typescript
npm warn   peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/typescript-estree@8.57.2
npm warn   node_modules/@typescript-eslint/typescript-estree
npm warn     @typescript-eslint/typescript-estree@"8.57.2" from @typescript-eslint/parser@8.57.2
npm warn     node_modules/@typescript-eslint/parser
npm warn     3 more (@typescript-eslint/type-utils, ...)
npm warn ERESOLVE overriding peer dependency
npm warn While resolving: @typescript-eslint/utils@8.57.2
npm warn Found: typescript@6.0.2
npm warn node_modules/typescript
npm warn   dev typescript@"^6.0.0" from the root project
npm warn   1 more (ts-api-utils)
npm warn
npm warn Could not resolve dependency:
npm warn peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/utils@8.57.2
npm warn node_modules/@typescript-eslint/utils
npm warn   @typescript-eslint/utils@"8.57.2" from @typescript-eslint/eslint-plugin@8.57.2
npm warn   node_modules/@typescript-eslint/eslint-plugin
npm warn   2 more (@typescript-eslint/type-utils, typescript-eslint)
npm warn
npm warn Conflicting peer dependency: typescript@5.9.3
npm warn node_modules/typescript
npm warn   peer typescript@">=4.8.4 <6.0.0" from @typescript-eslint/utils@8.57.2
npm warn   node_modules/@typescript-eslint/utils
npm warn     @typescript-eslint/utils@"8.57.2" from @typescript-eslint/eslint-plugin@8.57.2
npm warn     node_modules/@typescript-eslint/eslint-plugin
npm warn     2 more (@typescript-eslint/type-utils, typescript-eslint)
npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving: typescript-eslint@8.57.2
npm error Found: typescript@6.0.2
npm error node_modules/typescript
npm error   dev typescript@"^6.0.0" from the root project
npm error   peer typescript@">=4.8.4" from ts-api-utils@2.5.0
npm error   node_modules/ts-api-utils
npm error     ts-api-utils@"^2.4.0" from @typescript-eslint/eslint-plugin@8.57.2
npm error     node_modules/@typescript-eslint/eslint-plugin
npm error       @typescript-eslint/eslint-plugin@"8.57.2" from typescript-eslint@8.57.2
npm error       node_modules/typescript-eslint
npm error         dev typescript-eslint@"^8.38.0" from the root project
npm error     ts-api-utils@"^2.4.0" from @typescript-eslint/type-utils@8.57.2
npm error     node_modules/@typescript-eslint/type-utils
npm error       @typescript-eslint/type-utils@"8.57.2" from @typescript-eslint/eslint-plugin@8.57.2
npm error       node_modules/@typescript-eslint/eslint-plugin
npm error         @typescript-eslint/eslint-plugin@"8.57.2" from typescript-eslint@8.57.2
npm error         node_modules/typescript-eslint
npm error     1 more (@typescript-eslint/typescript-estree)
npm error
npm error Could not resolve dependency:
npm error peer typescript@">=4.8.4 <6.0.0" from typescript-eslint@8.57.2
npm error node_modules/typescript-eslint
npm error   dev typescript-eslint@"^8.38.0" from the root project
npm error
npm error Conflicting peer dependency: typescript@5.9.3
npm error node_modules/typescript
npm error   peer typescript@">=4.8.4 <6.0.0" from typescript-eslint@8.57.2
npm error   node_modules/typescript-eslint
npm error     dev typescript-eslint@"^8.38.0" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency resolution.
npm error
npm error
npm error For a full report see:
npm error /runner/cache/others/npm/_logs/2026-03-24T22_27_04_729Z-eresolve-report.txt
npm error A complete log of this run can be found in: /runner/cache/others/npm/_logs/2026-03-24T22_27_04_729Z-debug-0.log

[github-actions]

Open in Overmind ↗

---

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

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ Multiple compute resources showing unusual weekly changes at 1 event/week for the last 2-3 months, which is infrequent compared to typical patterns.

View signals ↗

---

🔥 Risks

Tip

✔ All risks disproven

We investigated 3 potential risks across 15 resources and verified each was safe. See the investigation details below.

---

🧠 Reasoning · ✔ 0 · ✖ 3

EBS DeleteOnTermination on updated instances risks data loss

Observations 2

Hypothesis

Multiple EC2 instances have attached EBS data volumes with DeleteOnTermination=true. When these instances are updated, replacement or termination of the instances can automatically delete the associated volumes (e.g., vol-090e750179b5fa681 on i-09d6479fb9b97d123 and vol-0a61278f4602fc12b on i-0464c4413cb0c54aa). If these volumes contain important data and there are no recent snapshots or backup/lifecycle policies, the change can cause irreversible data loss and violate data protection and compute-configuration best practices. Risk is mitigated by ensuring updates do not replace the instances, or by snapshotting / backing up volumes and defining clear snapshot lifecycle before the change.

Investigation

Evidence Gathered

I first loaded the relevant organizational guidance for compute and data protection: aws-compute-configuration, aws-data-protection, and security-compliance-requirements. Those files confirm that EBS deletion and unprotected data would be a valid concern if this change were actually replacing or terminating instances, and they also note that unencrypted EBS volumes are non-compliant.

I then checked the full planned changes for both EC2 instances, 540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123 and 540044833068.eu-west-2.ec2-instance.i-0464c4413cb0c54aa. The only diff shown for each instance is public_dns and public_ip changing from concrete values to (known after apply). There are no diffs to block device mappings, no diffs to DeleteOnTermination, no diffs to AMI, instance type, subnet, security groups, or any other force-replacement attributes, and the planned change type is updated, not replaced.

I queried the current blast-radius state for both instances and both attached volumes. That confirmed each instance has only its root EBS volume attached at /dev/xvda, and both attached volumes currently have DeleteOnTermination: true. It also confirmed the two volumes in question are vol-090e750179b5fa681 and vol-0a61278f4602fc12b. I checked AWS and Terraform documentation as well: Terraform commonly renders public_ip and public_dns as (known after apply) during in-place EC2 updates, and AWS documents that a stop/start cycle can reassign an auto-assigned public IPv4 address while attached EBS volumes persist through stop/start. AWS separately documents that attached EBS volumes persist across stop/start and that the default deletion behavior applies on termination, not on ordinary in-place updates. (developer.hashicorp.com)

Impact Assessment

The hypothesis points at 2 EC2 instances and 2 attached EBS root volumes. If these instances were being replaced or terminated, the blast radius would indeed include both volumes because they are attached with DeleteOnTermination=true. However, the actual plan does not show a replacement path for either instance; it shows an in-place update only. The operational effect supported by the evidence is limited to possible reassignment of the ephemeral public IPv4 addresses on the two instances after apply, not deletion of their EBS volumes. AWS documentation indicates that during stop/start, the instance can receive a new public IPv4 address, while attached EBS volumes and their data persist. (docs.aws.amazon.com)

So the directly affected resources are 2 EC2 instances: i-09d6479fb9b97d123 and i-0464c4413cb0c54aa. The data volumes identified by the hypothesis are not at risk of deletion from this specific change because there is no evidence that Terraform will terminate or replace either instance. I did note a separate compliance issue: both EBS volumes are currently unencrypted, which conflicts with organizational policy, but that is pre-existing state and not a failure introduced by this change.

Conclusion

I conclude the hypothesized data-loss risk is not real for this change. The key evidence is that both resources are planned as in-place updated instances with only public_ip/public_dns becoming unknown until apply, and AWS documents that attached EBS volumes persist across the stop/start behavior associated with such updates rather than being deleted. (developer.hashicorp.com)

✖ Hypothesis disproven

---

ENI/IP churn risks breaking internal DNS and static IP consumers

Observations 1

Hypothesis

An EC2 instance update may detach or replace an attached ENI with DeleteOnTermination=true (e.g., eni-0a8dc8648170059f4), reallocating its private IP address 10.0.101.11 that is referenced by internal DNS (ip-10-0-101-11.eu-west-2.compute.internal) or other static contracts. This can cause DNS to point to a non-existent or reassigned IP, breaking services that depend on that hostname or fixed IP. The risk is that network identity is pinned to an ephemeral ENI/IP instead of a stable abstraction. Mitigations include ensuring ENI persistence across instance refreshes, or automating DNS and dependent configuration updates when instances/ENIs are replaced.

Investigation

Evidence Gathered

I first checked the relevant organizational knowledge for EC2 and networking (aws-network-security, aws-compute-configuration, infrastructure-quick-reference, and multi-region-architecture). None of those files introduced a requirement that would make this specific diff risky, though they do reinforce that direct EC2 public endpoints are generally less stable than managed abstractions.

I then inspected the planned changes for both EC2 instances in this PR. For the instance named api-207c90ee-api-server (540044833068.eu-west-2.ec2-instance.i-09d6479fb9b97d123), the only concrete change shown is public_dns and public_ip becoming (known after apply). The instance's private_ip remains explicitly 10.0.101.11 in the diff. The second instance shows the same pattern for its public address only. There is no diff showing instance replacement, ENI replacement, subnet change, security group change, private IP change, or any network interface block changes.

I queried the current blast-radius state for the instance, its attached ENI eni-0a8dc8648170059f4, and the internal DNS record global.dns.ip-10-0-101-11.eu-west-2.compute.internal. The current state shows a single primary ENI attached to the instance with DeleteOnTermination: true, private IP 10.0.101.11, and private DNS ip-10-0-101-11.eu-west-2.compute.internal. The DNS record itself is just the AWS-generated A record for that private IP. I also checked the sibling instance and its ENI to compare the pattern; it is identical.

Finally, I verified AWS/Terraform behavior in the official docs. AWS documents that stopping and starting an EC2 instance typically causes an auto-assigned public IPv4 address to change, while attached network interfaces and their private IPv4 addresses persist across stop/start. HashiCorp's Terraform material also shows public_ip/public_dns commonly appearing as (known after apply) during in-place EC2 updates because those computed public values may be reassigned during apply, even when the resource is still shown as an in-place update. (docs.aws.amazon.com)

Impact Assessment

The hypothesis is concerned with one internal DNS name and one private IP: ip-10-0-101-11.eu-west-2.compute.internal → 10.0.101.11, tied to the primary ENI on api-207c90ee-api-server. Based on the actual plan, 1 EC2 instance is directly changing in a way that could affect its public address, but there is no evidence that its private network identity is changing. The blast radius contains the corresponding ENI and DNS objects, and both currently line up exactly with the instance's primary private IP.

Operationally, the likely effect of this change is limited to public internet reachability for any consumer pinned to the auto-assigned public IP or public DNS name. That is a different concern from the hypothesis. For the hypothesis's stated failure mode—internal DNS or static consumers of 10.0.101.11 breaking—there is no supporting evidence. The private IP remains fixed in the diff, the instance is not being replaced, and AWS documents that private IPs on attached ENIs persist across stop/start while auto-assigned public IPs may change. (docs.aws.amazon.com)

Conclusion

I am confident the hypothesized private-IP/ENI churn risk is not real for this change. The plan only indicates recomputation of the instance's public address fields; there is no evidence of ENI replacement or private IP change, and AWS behavior for stop/start preserves the attached ENI and its private IP. (docs.aws.amazon.com)

✖ Hypothesis disproven

---

Simultaneous public endpoint churn without stable front door or failover

Observations 3

Hypothesis

Public DNS and IPs for a pair of EC2 instances will both be reallocated during the update. Any external or operational dependency pinned to those public endpoints—such as scripts, SSM parameters, manual allowlists, synthetic tests, health checks, dashboards, and runbooks—can simultaneously go stale, breaking access and masking real service health. Updating both instances at once removes any stable, unchanged endpoint that can serve as a failover target; if the pair is used for redundancy or manual failover, delayed DNS/allowlist updates or a failed refresh can leave no reachable node. This creates rollout and reliability risk because all mutable endpoints change together instead of using a stable front door (e.g., load balancer, DNS name) or staggered updates, and it can undermine incident detection and response if observability tooling does not automatically discover the new addresses.

Investigation

Evidence Gathered

I first checked the relevant organizational guidance. aws-high-availability says to flag deployments that apply changes to all instances simultaneously when that removes gradual rollout or fault isolation, and it also emphasizes avoiding manual failover dependencies. I also checked infrastructure-quick-reference, which contains an important environment-specific note: the ovm-scale test environment contains dummy and relationship-density resources, but these two EC2 instances are not tagged as ovm-scale resources and instead carry Environment=production, so I treated them as real production instances.

I then queried the current state of both affected instances and their ENIs. Both instances are ordinary EC2 instances in the same subnet (subnet-07b5b1fb2ba02f964) and the same AZ (eu-west-2a), each with an auto-assigned public IPv4 address and public DNS name. Instance i-09d6479fb9b97d123 currently has public IP 35.179.137.86 and DNS ec2-35-179-137-86.eu-west-2.compute.amazonaws.com; instance i-0464c4413cb0c54aa currently has public IP 18.175.147.19 and DNS ec2-18-175-147-19.eu-west-2.compute.amazonaws.com. The planned changes for both resources show only public_ip and public_dns becoming (known after apply). No load balancer, Route53 record, Elastic IP, Auto Scaling Group, or other stable front-door resource is present in the change, and the queried current state shows neither instance has an Elastic IP attached.

I also checked AWS documentation. AWS documents that automatically assigned public IPv4 addresses are lost when an instance is stopped and started, and that starting the instance assigns a new public IPv4 address unless an Elastic IP is used. AWS also documents that changing the primary public IPv4 address invalidates the previous public hostname because the hostname is derived from the IP address.

Impact Assessment

Two production EC2 instances are directly affected: i-09d6479fb9b97d123 and i-0464c4413cb0c54aa. For both, the current internet-reachable endpoints will change together. That means there will be zero unchanged public endpoints left in this pair after the update.

However, the hypothesis depends on additional external or operational consumers being pinned to those exact public IPs or AWS-generated hostnames. I found no concrete evidence of such dependencies in the blast radius: no Route53 records, no Elastic IPs, no ALB, no SSM parameters, no monitoring resources, and no other internal resources referencing these public endpoints. The blast radius only confirms that the public endpoints themselves will churn, not that anything critical actually depends on them. The operational consequence is therefore unproven. Endpoint churn is real, but the claim that it will break access, failover, dashboards, synthetic checks, or incident response remains speculative with the evidence available.

Conclusion

I conclude the risk is not proven. The change will rotate both instances' auto-assigned public IPs and AWS-generated public DNS names, but I found no evidence of a real dependent front door, failover process, or operational tooling pinned to those endpoints, so the hypothesis does not clear the bar from plausible concern to demonstrated risk.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 15

Edges 44

[github-actions]

⛔ 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 15 · Edges 44

---

View full analysis in Overmind ↗