(aws-cdk-lib): cdk commands hang on Yarn install step when using Runtime.NODEJS_20_X

[petetnt]

Describe the bug

I am trying to run cdk commands, such as cdk diff on a stack that contains NodejsFunctions with runtimes set to Runtime.NODEJS_20_X. However, the commands always hang when the build image, public.ecr.aws/sam/build-nodejs20.x@sha256:f09695497aac919ac48544640265 tries to install yarn:

[+] Building 317.2s (4/13)
 => [internal] load build definition from Dockerfile                                             0.0s
 => => transferring dockerfile: 37B                                                              0.0s
 => [internal] load .dockerignore                                                                0.0s
 => => transferring context: 2B                                                                  0.0s
 => [internal] load metadata for public.ecr.aws/sam/build-nodejs20.x:latest                      0.9s
 => CACHED [ 1/10] FROM public.ecr.aws/sam/build-nodejs20.x@sha256:f09695497aac919ac48544640265  0.0s
 => [ 2/10] RUN npm install --global [email protected]                                               316.1s

If runtime is set to Runtime.NODEJS_18_X, yarn is installed correctly.

Also if one just takes the Dockerfile from https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-lambda-nodejs/lib/Dockerfile and sets ARG IMAGE=IMAGE=public.ecr.aws/sam/build-nodejs20.x, the yarn install step completes successfully.

Expected Behavior

Yarn is installed within seconds and the build continues.

Current Behavior

RUN npm install --global [email protected] step continues indefinitely

Reproduction Steps

Create a project that has a NodeJSFunction in it:

    const customMessageHandler = new NodejsFunction(this, 'CognitoMessageHandler', {
      memorySize: 128,
      timeout: Duration.seconds(5),
      runtime: Runtime.NODEJS_20_X,
      handler: 'handler',
      projectRoot: path.join(__dirname, '../../src/myproject'),
      depsLockFilePath: path.join(__dirname, '../../src/myproject/yarn.lock'),
      entry: path.join(__dirname, '../../src/myproject/src/index.ts'),
      bundling: {
        minify: true,
        loader: {
          '.html': 'text'
        }
      }
    });

Run cdk diff --profile myprofile

Possible Solution

No response

Additional Information/Context

Might be related to aws/aws-sam-build-images#116

CDK CLI Version

2.118.0 (build a40f2ec)

Framework Version

2.117.0

Node.js Version

v20.10.0

OS

macOS 13.1

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

I guess this is because the default bundling base image is sam/build-nodejs18.x while you are deploying to v20 lambda runtime and this might require you to specify ARG IMAGE= point to v20 for better compatibility.

aws-cdk/packages/aws-cdk-lib/aws-lambda-nodejs/lib/Dockerfile

Line 3 in 10ed194

ARG IMAGE=public.ecr.aws/sam/build-nodejs18.x

[petetnt]

As far as I understand, setting the runtime parameter to Runtime.NODEJS20_X does exactly that, it sets the IMAGE ARG to sam/build-nodejs18.x. I am not familiar enough with the internals of aws-cdk though.

[petetnt]

The issue went away after updating to MacOS Sonoma 14.2.1, which seem to point similar kinds of OpenSSL issues as with aws/aws-sam-build-images#116 but I don't think one can pass build args anyway.

Next run did hang on RUN npm install --global --unsafe-perm=true esbuild@0 once, but one more try helped

[gshpychka]

I guess this is because the default bundling base image is sam/build-nodejs18.x while you are deploying to v20 lambda runtime and this might require you to specify ARG IMAGE= point to v20 for better compatibility.

aws-cdk/packages/aws-cdk-lib/aws-lambda-nodejs/lib/Dockerfile

Line 3 in 10ed194

ARG IMAGE=public.ecr.aws/sam/build-nodejs18.x

This is not correct - the IMAGE argument is set automatically depending on the runtime selected. You can see in the log that the image being used is public.ecr.aws/sam/build-nodejs20.x

[jmongi]

@petetnt you can add esbuild as a dev dependency to prevent pulling the image from the public ECR.