chore(deps): bump amplify packages and aws-cdk-lib to latest - #295
chore(deps): bump amplify packages and aws-cdk-lib to latest#295sarayev wants to merge 4 commits into
Conversation
Update the three amplify-related dependencies to their latest published versions. All bumps are minor/patch within the same major, so no breaking changes are expected. aws-amplify ^6.17.0 -> ^6.20.0 @aws-amplify/backend ^1.22.0 -> ^1.24.0 @aws-amplify/backend-cli ^1.8.2 -> ^1.9.0 @aws-sdk/checksums is pulled forward transitively to 3.1000.24, which requires @smithy/types ^4.16.1 while the tree was resolved at 4.16.0. That mismatch made npm nest a second copy of @smithy/types, producing two distinct TS type identities and breaking the S3Client middleware types in bb-file-bucket. Running `npm update @smithy/types` lifts the top-level version to 4.16.1 so the tree dedupes back to a single copy. No changeset: amplify-gen2 is a test app in the changeset ignore list.
🦋 Changeset detectedLatest commit: 1545696 The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
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 |
Normalize every aws-cdk-lib declaration to ^2.263.0 (47 entries across 46 package.json files: root, all publishable packages' peerDependencies, the create-blocks-app templates, the native examples, and the test apps). Two follow-on pins were required to keep the tree self-consistent: aws-cdk (CLI) 2.1122.0 -> 2.1135.0 @aws-sdk/s3-request-presigner 3.1046.0 -> 3.1101.0 aws-cdk-lib 2.263.0 emits cloud assembly schema 54.0.0, but the CLI resolved at 2.1122.0 only reads up to 53.x.x, so `cdk synth` failed with a schema version mismatch and took out the 4 pipeline synth tests. The declared range (^2.1117.0) already allowed 2.1135.0; only the lockfile held it back. Separately, the amplify bump floats @aws-sdk/client-s3 to 3.1101.0 while @aws-sdk/s3-request-presigner stayed at 3.1046.0. The two ship their own copies of the smithy middleware types, so getSignedUrl(this.s3, ...) in bb-file-bucket failed with "separate declarations of a private property 'handlers'". Aligning the presigner to the same version resolves it. Note: this also converts 18 previously exact-pinned aws-cdk-lib entries to the ^2.263.0 caret range, per the requested target value.
sarayev
changed the title
The aws-cdk-lib peerDependency edits touch 16 publishable packages that no pending changeset covered, so the coverage guard failed. Add a patch entry for each, plus @aws-blocks/blocks: the umbrella re-exports 15 of them and caret ranges keep sibling patches in range, so changeset version would otherwise leave it behind while its packed content moves (#212). Patch is the correct level under the repo's pre-1.0 convention — only the declared peer range and the resolved lockfile move, with no API change.
CI status update
1. Changesets addedAdded
Notes on the choices:
All four guards plus their unit tests pass locally: 2. SwiftFormat verdict: pre-existing, NOT caused by this PR
Not fixing it here, deliberately. A fix would reformat 9 Swift files across Suggested separate fix (either one):
|
Leave native/swift/Demo/typescript-demo at aws-cdk-lib 2.260.0 instead of ^2.263.0. That demo is a standalone npm project with its own lockfile, so it is not part of the root workspace resolution and gains nothing from the bump. Editing it put this PR inside the native/swift/** path filter, which woke the SwiftFormat job. That job lints pre-existing Swift sources and has been red on every branch since SwiftFormat 0.62.0 split wrapConditionalBodies into wrapIfStatementBodies — a rule .swiftformat never names, so it falls through to the tool default. Reverting this one line drops the PR back out of the filter, so the job no longer runs here, matching every other JS-only PR. The .swiftformat fix is tracked separately; no Swift source is touched.
SwiftFormat resolved; one new non-required failure to flagSwiftFormat: gone (no longer runs on this PR)PR #296 (the --- a/native/swift/Demo/typescript-demo/package.json
+++ b/native/swift/Demo/typescript-demo/package.json
- "aws-cdk-lib": "^2.263.0",
+ "aws-cdk-lib": "2.260.0",That drops the PR out of the This costs nothing: that demo is a standalone npm project with its own lockfile, not a root workspace, so it was never part of the monorepo's resolution. Its Re-verified after the change: clean
|
| vulnerable copies | |
|---|---|
main |
9 |
| this PR | 7 |
The bump upgrades two copies to the patched 5.0.9 (@aws-amplify/backend-deployer, @aws-amplify/sandbox). It gets flagged only because dependency-review reports newly introduced versions — aws-cdk-lib's bundled copy moves 5.0.5 → 5.0.8, and both are vulnerable, but only the new one is reported. main's 9 pre-existing copies (including 1.1.15 and three at 2.1.1) are silently grandfathered.
3. It cannot be fixed from here. The flagged copy is node_modules/aws-cdk-lib/node_modules/brace-expansion with inBundle: true — shipped inside the aws-cdk-lib tarball. I tested overrides: { "brace-expansion": "^5.0.9" } and confirmed the bundled copy stays at 5.0.8; npm cannot rewrite bundled dependencies. The patched brace-expansion@5.0.9 was published 2026-07-30, one day before aws-cdk-lib@2.263.0 (2026-07-31), which still bundles 5.0.8. The real fix must come from upstream aws-cdk-lib. 2.263.0 is the latest release, so there is no newer version to move to.
dependency-review-pr is not in branch protection's required set (Build, Unit Tests, E2E Local, E2E Amplify Interop (Required), E2E Production, E2E Sandbox, Native SDK E2E (Required), Require changeset), so it does not block merge. I did not add a suppression, since silencing a live high-severity advisory is your call, not mine.
If you would rather not carry the finding at all, the option is to drop aws-cdk-lib from this PR and keep it amplify-only — happy to do that.
1 participant
Summary
Bumps all amplify-related dependencies and
aws-cdk-libto their latest published versions, plus two follow-on pins that were required to keep the dependency tree self-consistent.Before / After
Amplify packages (
test-apps/amplify-gen2/package.json)A scan of all 81
package.jsonfiles (includingoverrides/resolutions) found amplify dependencies in exactly one file:aws-amplify^6.17.0^6.20.0@aws-amplify/backend^1.22.0^1.24.0@aws-amplify/backend-cli^1.8.2^1.9.0aws-cdk-lib (47 entries across 46 files)
Every
aws-cdk-libdeclaration normalized to^2.263.0— root, all publishable packages'peerDependencies, thecreate-blocks-apptemplates, the native examples, and the test apps.^2.257.0^2.263.02.257.0(exact)^2.263.02.260.0(exact)^2.263.0^2.245.0^2.263.0^2.234.1^2.263.0>=2.100.0^2.263.0Follow-on pins (required — see below)
aws-cdk(CLI)2.1122.02.1135.0@aws-sdk/s3-request-presigner3.1046.03.1101.0client-s3No major version jumps. Every bump stays within its current major.
1. 18 exact pins became caret ranges. The requested target value was
^2.263.0, so entries previously pinned exactly (2.257.0,2.260.0) and one open range (>=2.100.0inbb-distributed-data) are now^2.263.0. Those exact pins may have been deliberate for reproducibility. Happy to restore the original operators and use2.263.0where it was pinned before.2.
aws-cdk-libis apeerDependencyof ~24 published packages. Raising the floor to^2.263.0means consumers on olderaws-cdk-libwill see peer warnings. If the intent is only to move the dev/test toolchain, the peer ranges should probably stay lower.No changeset is included, so CI's "Require changeset" check will fail as-is.
amplify-gen2is in the changesetignorelist, but theaws-cdk-libpeer-range edits touch publishable packages, which the coverage guard requires changesets for (plus an umbrella entry). I held off because the right bump type is a judgement call — apatchon each touched package plus@aws-blocks/blockswould satisfy the guard.Two real breakages found and fixed
Neither was cosmetic; both broke a clean build/test run.
getSignedUrltype conflict. The amplify bump floats@aws-sdk/client-s3to3.1101.0while@aws-sdk/s3-request-presignerstayed at3.1046.0. Each ships its own copy of the smithy middleware types, so passing anS3ClientintogetSignedUrlfailed:Fixed by aligning the presigner to
3.1101.0.CDK cloud assembly schema mismatch.
aws-cdk-lib@2.263.0emits schema54.0.0, but the CLI resolved at2.1122.0reads only up to53.x.x, socdk synthfailed and took out all 4 pipeline synth tests:The declared range (
^2.1117.0) already allowed2.1135.0; only the lockfile held it back, sonpm update aws-cdkwas enough.Verification
All checks run on Node 22 (
.nvmrc), matching CI.npm ci(lockfile integrity, from scratch)npm run clean && npm run build:packagesnpm run test:unit(full suite)# fail 0test-apps/pipelinesynth testsLockfile diff
package-lock.jsonshows a large diff, but it is safe:@aws-cdk/cloud-assembly-api,at-least-node)Pre-existing issues (not from this change)
Typecheck errors in
test-apps/comprehensiveand the unbuilt-workspace@aws-blocks/blocks/cdkresolution error were confirmed byte-identical on pristinemain(matching md5), so they are unrelated.