Skip to content

(aws-cdk-lib): Bundled cloud-assembly-api in 2.254.0+ declares dependencies that don't match what cdk ships, breaking npm ci #37944

Description

@bjpaolucci

Describe the bug

aws-cdk-lib 2.254.0 through 2.256.0 ship with a bundled
@aws-cdk/cloud-assembly-api whose package.json declares dependency
ranges that aren't satisfied by the versions cdk physically bundles in
the same tarball.

Concretely:

  • 2.254.0: bundled cloud-assembly-api 2.2.3 declares
    jsonschema: ~1.4.1, but cdk ships only jsonschema 1.5.0 at the
    cdk root and no nested copy.
  • 2.255.0 and 2.256.0: bundled cloud-assembly-api 2.2.4 declares
    semver: ^7.8.0, but cdk ships only semver 7.7.4.

npm install hoists the available version and works. npm ci
validates strictly and refuses with errors like:

Missing: [email protected] from lock file
Invalid: lock file's [email protected] does not satisfy [email protected]

This breaks any CI flow that uses npm ci (Bitbucket Pipelines, AWS
CodeBuild, GitHub Actions all default to npm ci for clean installs).

The earlier 2.246.0 release shipped a deeper nested layout
(node_modules/aws-cdk-lib/node_modules/@aws-cdk/cloud-assembly-api/node_modules/[email protected])
which kept everything self-consistent. The newer releases dropped the
deep nesting without aligning the declared ranges.

Reproduction:

mkdir repro && cd repro
npm init -y
npm install --save-exact [email protected]
npm ci

=> error: Missing: [email protected] from lock file

Regression Issue

  • Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

2.246.0

Expected Behavior

npm ci against a freshly generated package-lock.json should succeed.

Either:

  • bundle a nested [email protected] / [email protected] alongside
    @aws-cdk/cloud-assembly-api so the declared ranges resolve, or
  • bump the cloud-assembly-api dependencies in its bundled
    package.json so the ranges match the actual bundled versions
    (jsonschema ^1.5.0, semver ^7.7.4).

Current Behavior

npm ci fails with EUSAGE saying the lockfile is out of sync, even
when the lockfile was just generated by npm install against the same
package.json.

Reproduction Steps

mkdir cdk-npm-ci-repro && cd cdk-npm-ci-repro
npm init -y
npm install --save-exact [email protected]

package-lock.json is generated, install completes successfully

npm ci

fails:

npm error code EUSAGE

npm error npm ci can only install packages when your package.json

npm error and package-lock.json or npm-shrinkwrap.json are in sync.

npm error Missing: [email protected] from lock file

Same flow with 2.255.0 or 2.256.0 fails differently:

Invalid: lock file's [email protected] does not satisfy [email protected]

Possible Solution

The bundled @aws-cdk/cloud-assembly-api/package.json declares dependency
ranges that don't match the versions cdk physically bundles in the
aws-cdk-lib tarball. Either:

  1. Bundle the matching nested dependencies (the layout 2.246.0 used:
    node_modules/aws-cdk-lib/node_modules/@aws-cdk/cloud-assembly-api/node_modules/{jsonschema,semver}),
    or
  2. Update the dependencies declared in the bundled cloud-assembly-api
    package.json so the ranges match what's shipped at the cdk root
    (jsonschema ^1.5.0, semver ^7.7.4).

Option 2 is smaller and avoids re-introducing duplicate copies of
jsonschema/semver in the cdk tarball.

Additional Information/Context

Triggered by trying to bump aws-cdk-lib past 2.246.0 to clear the
high-severity fast-uri advisory (GHSA path traversal / host confusion,
fixed in fast-uri 3.1.2 which is first bundled by aws-cdk-lib 2.254.0).

Per-version observations from inspecting the published tarballs:

  • 2.246.0: bundle is self-consistent. cloud-assembly-api ships its own
    nested [email protected] and [email protected]. npm ci works.
  • 2.247.0 through 2.253.1: still vulnerable fast-uri 3.1.0.
  • 2.254.0: bundled cloud-assembly-api 2.2.3 declares
    jsonschema: ~1.4.1, but cdk no longer ships the nested 1.4.1 — only
    jsonschema 1.5.0 is at the cdk root.
  • 2.255.0 and 2.256.0: bundled cloud-assembly-api 2.2.4 declares
    semver: ^7.8.0, but cdk still ships only semver 7.7.4 at the root.

Repos that use npm ci (Bitbucket Pipelines, AWS CodeBuild, GitHub
Actions clean install flows) cannot adopt 2.254.0+ without a manual
lockfile workaround. We pinned to 2.254.0 and edited the lockfile to
relax the declared jsonschema range to ^1.5.0, but this is fragile
since any later npm install rewrites the lockfile.

AWS CDK Library version (aws-cdk-lib)

2.254.0

AWS CDK CLI version

2.1122.0 (build c8f270c)

Node.js Version

v26.0.0

OS

macOS 25.5.0 (Darwin). Also reproduces on Linux (node:22 docker image used by Bitbucket Pipelines).

Language

TypeScript

Language Version

5.9.3

Other information

This is a regression introduced between 2.246.0 (last known good) and
2.254.0. The 2.246.0 tarball ships a deeply nested
node_modules/aws-cdk-lib/node_modules/@aws-cdk/cloud-assembly-api/node_modules/{jsonschema,semver}
that satisfies the declared ranges. Newer tarballs dropped the deep
nesting without aligning the declared dependencies in the bundled
@aws-cdk/cloud-assembly-api/package.json.

The motivating bump for affected teams is the high-severity fast-uri
advisory (path traversal / host confusion, fixed in fast-uri 3.1.2,
first bundled by aws-cdk-lib 2.254.0). Teams that use npm ci in CI
cannot pick up the security fix without a manual lockfile workaround.

Workaround used in our repo: pin aws-cdk-lib to an exact version and
edit package-lock.json to relax the declared cloud-assembly-api
range to match what's actually shipped (e.g. jsonschema ^1.5.0
instead of ~1.4.1). Fragile because any later npm install
rewrites the lockfile.

Inspecting the published tarballs (npm pack aws-cdk-lib@<v> then
tar -xzOf ... package/node_modules/@aws-cdk/cloud-assembly-api/package.json)
confirms the mismatch on 2.254.0 (jsonschema), 2.255.0 and 2.256.0
(semver).

Metadata

Metadata

Assignees

No one assigned

    Labels

    aws-cdk-libRelated to the aws-cdk-lib packagebugThis issue is a bug.potential-regressionMarking this issue as a potential regression to be checked by team member

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions