Bug: CDK typescript project fails with "Runtime.ImportModuleError" when running sam local about aws-sam-cli HOT 7 CLOSED

Hey @yiluhe-fpd, can I see some more of your configuration? I was able to get it to work on my end. My setup looks like

CDK Lambda function config

new nodejs.NodejsFunction(this, "MyFunction", {
      entry: path.join(__dirname, "../functions/app.ts"),
      handler: "parseJwtToken",
      runtime: Runtime.NODEJS_20_X,
      timeout: Duration.minutes(15),
      bundling: {
        minify: true,
      },
});

Lambda function code

export const parseJwtToken = (event: APIGatewayProxyEvent): LambdaResponse => {
  const authToken =
    event.headers["Authorization"] || event.headers["authorization"];

  if (!authToken) {
    return { statusCode: 500, body: JSON.stringify({ something: "failed" }) };
  }

  const token = authToken.split(" ")[1];
  const decoded = jwt.verify(token, process.env.JWT_SECRET!) as jwt.JwtPayload;
  if (!decoded.sub) {
    return { statusCode: 500, body: JSON.stringify({ something: "failed" }) };
  }

  return { statusCode: 200, body: JSON.stringify({ something: "succeeded" }) };
};

Also to note, with this setup you shouldn't be running sam build. The cdk synth should take care of building the function code and generating required assets in the construct.

from aws-sam-cli.

Hello and thank you for the response. My CDK code for Lambda definition is the following. It is using the FunctionProps as mentioned here: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda.FunctionProps.html. It is not the same as your approach and I would like to understand the difference, and if there is way to fix my approach.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
// import * as sqs from 'aws-cdk-lib/aws-sqs';

export class EmployerApiStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);

// Define the Lambda function
const myLambda = new lambda.Function(this, 'EmployerLambda', {
  runtime: lambda.Runtime.NODEJS_20_X,
  handler: 'index.handler',
  code: lambda.Code.fromAsset('./src'),
});

}
}

from aws-sam-cli.

Can you try using the L2 NodejsFunction construct and see if that fixes the issue for you?

from aws-sam-cli.

Great! Using NodejsFunction works! Can you tell me what's difference between the 2 approach? I see the following output when running CDK Synth with NodejsFunction, which didn't happen with lambda.Function. Is it a bug related to lambda.Function?

[+] Building 52.5s (14/14) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 1.30kB 0.0s
=> [internal] load metadata for public.ecr.aws/sam/build-nodejs20.x:latest 0.8s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [ 1/10] FROM public.ecr.aws/sam/build-nodejs20.x:latest@sha256:a69eaec5c26548c5acc107db8f99ece8d394a4c60b9ff 30.1s
=> => resolve public.ecr.aws/sam/build-nodejs20.x:latest@sha256:a69eaec5c26548c5acc107db8f99ece8d394a4c60b9ffe44 0.0s
=> => sha256:acf38c9ddfa51c5d4d868ce924400c553daa359362aaeaf0f14e0d9285101970 253.59MB / 253.59MB 12.5s
=> => sha256:8c011a14df013d37d34b5382e934324551678c42cef64eea45f9bb98a5f36726 57.99MB / 57.99MB 4.2s
=> => sha256:a69eaec5c26548c5acc107db8f99ece8d394a4c60b9ffe4462c3a873059c445c 743B / 743B 0.0s
=> => sha256:406ad47f0c3370d5a13adba666f0cd74333b90ca400b8585c9c97c211c06394b 3.69kB / 3.69kB 0.0s
=> => sha256:56cc389a078d6a55ad2a6a8db2978027c1def36eaadaae3b7624784b10825c70 86.08MB / 86.08MB 5.9s
=> => sha256:d0e8c276e2e874072a3a0d2540a04040aad55193dabbc773bc51e5803eabf5ff 9.35kB / 9.35kB 0.0s
=> => sha256:7859e0802c2afa770bff9ea17043d2f8c0a7b5236caacf1e4db221a206763e2e 72.68MB / 72.68MB 8.8s
=> => sha256:2bdf27323307fb3153840f0c2bfa565404833ff5d29d8c179409cbc8dda72bd2 4.81kB / 4.81kB 6.0s
=> => extracting sha256:56cc389a078d6a55ad2a6a8db2978027c1def36eaadaae3b7624784b10825c70 5.7s
=> => sha256:cd75de67102ad6e440afb2797d14932629fd220fd899bb7d8eb0664c6b0cbf8e 2.11MB / 2.11MB 6.3s
=> => sha256:f9d26094117c5d3d2a50e920fde0269971984c5081977094e10d46d3e8cbe603 8.82MB / 8.82MB 7.1s
=> => sha256:76647c7d243e0f180441b262646e68cb45d29e9eac1a1d973c653499d2ae62e9 178.00kB / 178.00kB 7.2s
=> => sha256:9491ad7ecb21731181b9824803748618455cc27f97631fdf3f313baaee03f47e 233.90kB / 233.90kB 7.3s
=> => sha256:c15ec4da029bb9554c9392259cc84995ea304d466c1d991c623b7f7aeb6a672a 122.19kB / 122.19kB 7.4s
=> => extracting sha256:acf38c9ddfa51c5d4d868ce924400c553daa359362aaeaf0f14e0d9285101970 8.8s
=> => extracting sha256:8c011a14df013d37d34b5382e934324551678c42cef64eea45f9bb98a5f36726 3.2s
=> => extracting sha256:7859e0802c2afa770bff9ea17043d2f8c0a7b5236caacf1e4db221a206763e2e 2.2s
=> => extracting sha256:2bdf27323307fb3153840f0c2bfa565404833ff5d29d8c179409cbc8dda72bd2 0.0s
=> => extracting sha256:cd75de67102ad6e440afb2797d14932629fd220fd899bb7d8eb0664c6b0cbf8e 0.0s
=> => extracting sha256:f9d26094117c5d3d2a50e920fde0269971984c5081977094e10d46d3e8cbe603 0.7s
=> => extracting sha256:76647c7d243e0f180441b262646e68cb45d29e9eac1a1d973c653499d2ae62e9 0.0s
=> => extracting sha256:9491ad7ecb21731181b9824803748618455cc27f97631fdf3f313baaee03f47e 0.0s
=> => extracting sha256:c15ec4da029bb9554c9392259cc84995ea304d466c1d991c623b7f7aeb6a672a 0.0s
=> [ 2/10] RUN npm install --global [email protected] 8.2s
=> [ 3/10] RUN npm install --global [email protected] 2.1s
=> [ 4/10] RUN npm install --global typescript 1.8s
=> [ 5/10] RUN npm install --global --unsafe-perm=true esbuild@0 2.8s
=> [ 6/10] RUN mkdir /tmp/npm-cache && chmod -R 777 /tmp/npm-cache && npm config --global set cache /tmp 1.2s
=> [ 7/10] RUN mkdir /tmp/yarn-cache && chmod -R 777 /tmp/yarn-cache && yarn config set cache-folder /tm 1.2s
=> [ 8/10] RUN mkdir /tmp/pnpm-cache && chmod -R 777 /tmp/pnpm-cache && pnpm config --global set store-d 1.7s
=> [ 9/10] RUN npm config --global set update-notifier false 1.2s
=> [10/10] RUN /sbin/useradd -u 1000 user && chmod 711 / 0.6s
=> exporting to image 0.3s
=> => exporting layers 0.3s
=> => writing image sha256:3c4fc5438b5454e0445ef524ede74b48ee111ca5a01ced8cbc0c8cd8b2baac14 0.0s
=> => naming to docker.io/library/cdk-3c33a81cedb01f8fc7ad2fa7b736f3a13e329372ea7acda82779dec137eb24a6 0.0s

from aws-sam-cli.

This isn't a bug in the construct, it's just that the NodejsFunction construct provides a layer of abstraction around the base Function construct that also "builds" the function code. In SAM CLI, to build TS functions you need to specify the BuildMethod: esbuild in the function metadata. Since the produced CloudFormation configuration for the Function construct doesn't do this, SAM CLI doesn't know how to build the TS.

I recommend using the NodejsFunction construct since it addresses the issue. If you really want to test with the L1 construct, you can always add that BuildMethod property to the produced CFN template, run a sam build and then a sam local .. against the generated .aws-sam/build assets (though this is a hacky workaround that I don't recommend).

To understand more about these various constructs and how they interact with SAM CLI, you can look through these links:
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-cdk-building.html
https://docs.aws.amazon.com/cdk/v2/guide/constructs.html

Please let us know if you have anymore questions, otherwise I will mark this issue as resolved.

from aws-sam-cli.

Thank you very much for the help and explanation. Closing the issue.

from aws-sam-cli.

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

from aws-sam-cli.