fix(e2e-sandbox): restore cloud-assembly-schema <=53 compatibility after aws-cdk-lib bump

[soberm]

Problem

After #749 bumped aws-cdk-lib to ^2.246.0 (remediating GHSA-999r-qq7v-r334), the post-merge Sandbox E2E Tests job on main began failing during synth→deploy with a cloud-assembly schema mismatch:

[ERROR] [UnknownFault] Error: Cannot read asset manifest '.../cdk.out/amplify-basictodo-basicTodo-sandbox-76ae4b1b4d.assets.json':
Cloud assembly schema version mismatch: Maximum schema version supported is 53.x.x, but found 54.0.0

The caret range ^2.246.0 floats to aws-cdk-lib@2.260.0, which depends on @aws-cdk/cloud-assembly-schema@^54.0.0 and therefore emits schema 54.0.0 into *.assets.json. The deployer that reads that manifest — @aws-amplify/backend-cli@1.8.3 (the current latest) via @aws-amplify/backend-deployer — only supports cloud-assembly-schema ≤ 53.x.x. The result is a hard failure when ampx sandbox reads the synthesized manifest.

Only the sandbox workspace is affected because it is the only e2e workspace that performs a real ampx sandbox synth→deploy that reads the asset manifest. The node/vite/webpack/exports-test workspaces consume a pre-deployed amplify_outputs.json and never synth, so they did not surface the mismatch. The pr.yml checks run no e2e synth job, so the regression only appeared post-merge in push-main-release.yml.

Issue number, if available: N/A (post-merge regression introduced by #749)

Changes

Root cause — the schema 53→54 boundary. Querying the npm registry for the @aws-cdk/cloud-assembly-schema dependency of each aws-cdk-lib release establishes the exact boundary:

aws-cdk-lib	declares @aws-cdk/cloud-assembly-schema	emitted *.assets.json version
2.246.0 – 2.257.0	^53.x.x	53 ✅
2.258.0 – 2.260.0	^54.0.0	54 ❌

So 2.258.0 is the first aws-cdk-lib version that emits schema 54, and 2.257.0 is the highest version that is both patched (≥ 2.246.0, so GHSA-999r-qq7v-r334 stays fixed) and still emits schema 53 (deployer-compatible).

Option B is impossible. Bumping the deployer to support schema 54 is not an option: @aws-amplify/backend-cli@1.8.3 is already the latest published version, and no newer release supports schema 54.

Fix — Option A (minimal, scoped): pin all five e2e workspaces to the exact version aws-cdk-lib@2.257.0 (exact, no caret). The exact pin is required because the sandbox workspace's clean/install:no-lock scripts delete the lockfile and run a fresh yarn install, so a caret range would re-float to 2.260.0.

Files changed:

• packages/e2e-tests/{sandbox,node,vite,webpack,exports-test}/package.json — aws-cdk-lib: ^2.246.0 → 2.257.0
• yarn.lock — regenerated: aws-cdk-lib@2.260.0 → 2.257.0, @aws-cdk/cloud-assembly-schema@54.5.0 → 53.28.0 (no ^54.x refs remain)

Bonus — three additional open Dependabot alerts closed (moderate; currently open on main):

#	GHSA	Package	Fix
200	GHSA-h67p-54hq-rp68	js-yaml	Replaced the two scoped js-yaml resolutions with a single global "js-yaml": "^4.2.0", which evicts a remaining js-yaml@3.14.2 straggler (pulled transitively via read-yaml-file). Verified the read-yaml-file safeLoad path is not exercised by this monorepo (changeset status runs clean), so the 3→4 bump is safe.
214	GHSA-mx8g-39q3-5c79	webpack-dev-server	Resolution ^5.2.4 → ^5.2.5 + direct dep bump in packages/e2e-tests/webpack/package.json.
215	GHSA-64mm-vxmg-q3vj	http-proxy-middleware	Added resolution "http-proxy-middleware": "^2.0.10".

A changeset (.changeset/fix-e2e-sandbox-cloud-assembly-schema.md) is included for the check-changeset gate; it is empty (no published-package changes) since this only touches e2e test infra and dev tooling.

Corresponding docs PR, if applicable: N/A

Validation

Empirical schema proof. Because a real sandbox deploy requires live AWS us-west-2 credentials, schema compatibility was proven by synthesizing a standalone CDK app with each aws-cdk-lib version and inspecting the version field in the generated cdk.out/*.assets.json. The emitted schema is a function of the aws-cdk-lib version (its bundled @aws-cdk/cloud-assembly-schema), not of stack contents:

aws-cdk-lib	resolved cloud-assembly-schema	*.assets.json version	deployer (max 53.x.x)
2.257.0 (the fix)	53.28.0	53.0.0	✅ accepted
2.260.0 (old float)	54.5.0	54.0.0	❌ rejected (reproduces the CI error verbatim)

Build + test suite (local, Node 24 / Yarn 4.13.0):

• yarn install --immutable — ✅ exit 0 (lockfile consistent; no ^54.x cloud-assembly-schema refs)
• yarn build — ✅ 4/4 tasks
• yarn check:api — ✅ 2/2 tasks (no API surface changes)
• yarn lint — ✅ 3/3 tasks
• yarn test:scripts — ✅ 4/4
• yarn e2e-exports — ✅ fresh install with aws-cdk-lib@2.257.0 + rollup build, exit 0
• yarn changeset status --since origin/main — ✅ exit 0

Pre-existing failure (not introduced here): the integration-tests package fails locally with TS2304: Cannot find name '__filename' (its tsconfig.json sets "types": ["jest"], excluding @types/node). This passes 60/60 in CI and is logically independent of an aws-cdk-lib version pin — it fails identically on a clean main checkout.

This PR changes only e2e test-infra dependency pins, dev-tooling resolutions, and the lockfile — there is no runtime or type-level behavior change to the published packages, so no new automated tests are required. The functional change (sandbox synth emitting deployer-compatible schema 53) is validated by the standalone synth proof above and will be exercised end-to-end by the post-merge Sandbox E2E Tests job.

Checklist

• If this PR includes a functional change to the runtime or type-level behavior of the code, I have added or updated automated test coverage for this change. (N/A — test-infra/tooling/lockfile only; no published runtime or type changes)
• If this PR requires a docs update, I have linked to that docs PR above. (N/A — no docs change)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

🦋 Changeset detected

Latest commit: 8f5d822

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 0 packages

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR