[MarcAstr0]

Summary

#1605 (released as 4.0.4) fixed the cdktn 0.23 toolchain advisories with repo-local overrides only. npm and pnpm ignore a dependency's overrides, so apps installing Booster 4.0.4 still get the vulnerable versions:

• @cdktn/hcl2cdk@0.23.3 pins zod@3.25.76 (GHSA high, <4.6.6), which reaches consumers through cdktn-cli.
• cdktn@0.23.3 bundles fflate@0.8.2 (moderate). It is a bundled dependency, so no override can patch it.

cdktn 0.25.0 fixes both: hcl2cdk moves to zod ^4.4.3, and cdktn bundles fflate@0.8.3. The 0.24 line is still in the vulnerable range.

This also unblocks a coherent peer range for rocket-file-uploads-azure-infrastructure. Today it peers @cdktn/provider-azurerm >= 16.0.0 next to cdktn ^0.23.0, so a fresh npm install picks provider-azurerm 19 and fails with ERESOLVE.

What changed

• framework-provider-azure-infrastructure, framework-integration-tests: cdktn and cdktn-cli 0.23.3 → 0.25.0.
• framework-provider-azure-infrastructure: @cdktn/provider-azurerm 16.4.0 → 19.0.0, @cdktn/provider-null 13.1.0 → 16.0.0, @cdktn/provider-time 13.1.0 → 15.0.0. These are the only versions that peer on cdktn ^0.25.0.
• terraform-event-hub.ts: azurerm 5 removed namespace_name and resource_group_name from azurerm_eventhub, so the resource now uses namespace_id. This was the only compile error.
• pnpm-lock.yaml: regenerated with rush update.
• application-synth.ts: the azurerm provider sets resourceProviderRegistrations: 'legacy'. azurerm 5 changed the default from legacy to none, which would stop Terraform registering the resource providers Booster needs on a fresh subscription.
• Node engine: framework-provider-azure-infrastructure and framework-integration-tests now require >=22.23.4 <23.0.0, because cdktn-cli@0.25.0 declares node >=22.23.4. The other packages keep >=22.0.0. The installation docs now describe Booster 4.x and this requirement.
• Change file: minor.

⚠️ Terraform azurerm 4.x → 5.x

provider-azurerm 19.0.0 wraps Terraform azurerm 5.11 (16.4.0 wrapped 4.76). Every Azure app deployed with this version upgrades its Terraform provider by a major version. That is the main risk in this PR, and the reason for minor instead of patch. Reviewers may prefer major.

Other azurerm 5 default changes that touch Booster resources: azurerm_storage_account.allow_nested_items_to_be_public now defaults to false. Booster's and rocket-file-uploads' containers are all private, so on existing deployments this shows up as an in-place update, not a replacement.

Verification

• Clean tsc -b of framework-provider-azure-infrastructure (dist and tsbuildinfo removed first).
• rush rebuild of the Azure infrastructure package, the integration-test app and their dependencies: 13 operations succeeded.
• framework-provider-azure-infrastructure unit tests: 18 passing.
• Synthesized the integration-test app (provider block includes "resource_provider_registrations": "legacy") for Azure, with event streams and subscriptions forced on so the Event Hub and Web PubSub paths are included. Ran terraform init + terraform validate on the output: azurerm v5.11.0 installed, "The configuration is valid", no warnings.

Not verified

• Integration tests (deploy, functional, nuke on Azure). They will be triggered separately.
• Upgrade of an existing deployment. validate does not check how azurerm 5 treats state created by 4.x. A terraform plan against a 4.0.4 deployment should show no replace actions, especially on the Event Hub after the switch to namespace_id.
• Peer warning: rush update reports an unmet @opentelemetry/api peer (<1.10.0, found 1.10.0) inside cdktn-cli's own @sentry/node dependencies. It is upstream and left as is.

Follow-up

rocket-file-uploads needs a release after this one, peering cdktn ^0.25.0, @cdktn/provider-azurerm ^19.0.0 and Booster ≥ this version, with its cdktn-cli / @cdktn/hcl2cdk overrides removed.

🤖 Generated with Claude Code

[what-the-diff]

PR Summary

• Upgraded infrastructure dependencies to newer CDKTF and Azure provider versions, bringing security updates and improved provider support.
• Simplified Event Hub configuration by referencing the namespace directly, reducing the need to pass separate resource group and namespace details.
• Documented the changes in the project’s change log.

[MarcAstr0]

/integration sha=07d0874

[github-actions]

⌛ Integration tests are running...

Check their status here 👈

[MarcAstr0]

AI-assisted review by Codex of commit 07d08745118620f132c192dc2789c2334cacbcdb.

Recommendation: request changes.

1. [P1] Preserve Azure resource-provider registration when upgrading to AzureRM 5. The provider upgrade in packages/framework-provider-azure-infrastructure/package.json:33 changes the default for resource_provider_registrations from legacy to none. ApplicationSynth currently sets neither resourceProviderRegistrations nor resourceProvidersToRegister; I confirmed both are absent from its synthesized provider configuration. Deployments to subscriptions missing the required Azure resource-provider registrations can consequently fail. Tests against an established subscription may pass because those providers are already registered. Explicitly register the providers Booster needs, or preserve the previous behavior with resourceProviderRegistrations: 'legacy'. See the official AzureRM 5 migration guide. This finding is based on the documented default change and synthesized configuration; I did not deploy to a fresh subscription.

2. [P2] Align the advertised Node requirement with the new CLI dependency. cdktn-cli@0.25.0, added at packages/framework-provider-azure-infrastructure/package.json:41, declares Node >=22.23.4, while Booster's package still advertises >=22.0.0 <23.0.0. Users on versions currently advertised as supported will encounter installation failures when engine enforcement is enabled. Update the supported engine range and associated setup guidance, or use a compatible toolchain.

Validation: forced TypeScript compilation of the Azure infrastructure package passed, and all 18 Azure infrastructure unit tests passed. Cloud integration run 40764712439 was still running when I checked during the review. I did not independently run cloud deployment/teardown or validate migration of existing Terraform state.

[github-actions]

❌ Oh no! Integration tests have failed

[github-actions]

⌛ Integration tests are running...

Check their status here 👈

[github-actions]

❌ Oh no! Integration tests have failed

[MarcAstr0]

/integration sha=6bee8f0

[github-actions]

⌛ Integration tests are running...

Check their status here 👈

[github-actions]

❌ Oh no! Integration tests have failed

[github-actions]

✅ Integration tests have finished successfully!

[MarcAstr0]

AI-assisted follow-up review by Codex of commit 6bee8f09e286a6bcb91ebe12089c9dbce7f77aa1.

Recommendation: approve. This supersedes my earlier request-changes recommendation. Both findings are resolved, and I found no new blocking issues in the revision.

• Confirmed the synthesized AzureRM provider configuration explicitly sets resource_provider_registrations: "legacy", preserving the previous registration behavior.
• Confirmed the Azure infrastructure and integration-test packages now require Node >=22.23.4 <23.0.0, with installation guidance updated accordingly.
• Forced Azure infrastructure compilation and all 18 unit tests passed locally; the PR checks passed.
• Verified integration run 40856240488 completed successfully, including Azure deployment, both Azure functional suites, Azure teardown, CLI tests, and local-provider tests. Its preparation log confirms it checked out the merge containing this reviewed commit.

Remaining validation limitation: this evidence does not establish the upgrade behavior of existing Terraform state created with AzureRM 4.x. I did not independently validate that migration.