Runtime.ImportModuleError: Missing '@smithy/config-resolver' Dependency in @aws-sdk/client-sqs Package on AWS Lambda

[jpgrace]

Checkboxes for prior research

• [X] I've gone through Developer Guide and API reference
• [X] I've checked AWS Forums and StackOverflow.
• [X] I've searched for previous similar issues and didn't find any solution.

Describe the bug

Our project, which utilizes @aws-sdk/client-sqs as a dependency, consistently encounters a Runtime.ImportModuleError when deployed to AWS Lambda. This error points towards the inability to find the @smithy/config-resolver module, a listed dependency in @aws-sdk/client-sqs.

This issue has been consistently reproduced across versions 3.365.0, 3.369.0, and 3.370.0 of the @aws-sdk/client-sqs module. The project uses pnpm for managing dependencies. We have not tried with any other versions.

SDK version number

@aws-sdk/client-sqs@3.370.0 (latest)

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

Lambda Runtime: Node.js 18.x

Reproduction Steps

1. Install the @aws-sdk/client-sqs package in a Node.js project.
2. Deploy the project to AWS Lambda.
3. Invoke the Lambda function.
4. Observe the error in the CloudWatch logs.

Observed Behavior

The error log from AWS Lambda is as follows:

{
    "errorType": "Runtime.ImportModuleError",
    "errorMessage": "Error: Cannot find module '@smithy/config-resolver'\nRequire stack:\n- /var/task/node_modules/@aws-sdk/client-sqs/dist-cjs/SQSClient.js\n- /var/task/node_modules/@aws-sdk/client-sqs/dist-cjs/index.js\n- /var/task/lib/index.js\n- /var/runtime/index.mjs",
    "stack": [
        "Runtime.ImportModuleError: Error: Cannot find module '@smithy/config-resolver'",
        "Require stack:",
        "- /var/task/node_modules/@aws-sdk/client-sqs/dist-cjs/SQSClient.js",
        "- /var/task/node_modules/@aws-sdk/client-sqs/dist-cjs/index.js",
        "- /var/task/lib/index.js",
        "- /var/runtime/index.mjs",
        "    at _loadUserApp (file:///var/runtime/index.mjs:997:17)",
        "    at async UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1032:21)",
        "    at async start (file:///var/runtime/index.mjs:1195:23)",
        "    at async file:///var/runtime/index.mjs:1201:1"
    ]
}

Expected Behavior

The AWS SDK should correctly include all necessary dependencies when installed, and there should be no import errors when the SDK is used in a Lambda function.

Possible Solution

While @smithy/config-resolver is correctly listed as a dependency in @aws-sdk/client-sqs's package.json, it appears that there might be an issue with how this dependency is resolved at runtime in the AWS Lambda environment.

It is advised to investigate if there's an issue in how the SDK or its build process creates a path to this dependency, especially when running in AWS Lambda. Is there any particular scenario where pnpm might handle this dependency differently than npm or yarn?

The workaround for users currently is to manually add @smithy/config-resolver as a direct dependency in the project's package.json, which is not ideal and could lead to version conflict issues.

Additional Information/Context

The issue only occurs in the AWS Lambda environment and does not show up during local development or testing. This indicates that the problem is likely related to how the module is being bundled or resolved in the production deployment on AWS Lambda.

We hope this information assists you in addressing the issue. If you require further details or have additional questions, please let us know.

[yenfryherrerafeliz]

Hi @jpgrace, sorry to hear about your issue. Could you please let me know if you are, either uploading your node_modules folder when deploying to lambda?, or are you using a lambda layer?. The reason I ask this is because, the version of the SDK embedded in nodejs runtime is 3.188.0, which can be confirmed here, and that version does not contain those new changes since they were presumable introduced after version 3.363.0 , by the following commit here.

Please let me know.

Thanks!

[jpgrace]

Hi, thank you for your prompt response!

To provide some context, this is my first time working with this SDK, and I've been encountering this issue since my initial attempts. I'm using a monorepo setup with pnpm, where each Lambda function is a separate sub-project. As part of my CICD, I run a build step that includes type checking and pruning the development dependencies with pnpm install --prod.

My deployment process involves creating a zip archive for each of these sub-projects, which includes the specific node_modules directory for that sub-project along with the relevant source files. I am not using a Lambda layer for dependencies.

I've been using version 3.365.0 or later of the SDK. While I'm aware that the Node.js runtime on AWS Lambda comes with version 3.188.0 of the SDK, my understanding was that the version of the SDK in my uploaded bundle would take precedence.

I hope this provides some clarity about the situation. I'm looking forward to your insights into what might be causing this issue and any guidance on how to get it working.

[linbasil]

Hi @jpgrace, I had the same issue as you and @yenfryherrerafeliz is correct - Lambda Node 18 runs version 3.188.0 of the AWS SDK.

Because you are including aws-sdk packages explicitly as a dependency (and presumably bundling the node modules as part of your Lambda build), Lambda will attempt to use your aws-sdk version rather than the Lambda built-in version. The version you have explicitly defined does not work with Lambda's default packages, hence the issue you see.

I solved this by defining the aws-sdk packages as a devDependency, and pruning them out as part of deployments in order to allow Lambda to import the versions of the SDK already built-in. You can remove them altogether from your package.json if you wish, but I did this to prevent any linting issues with my IDE and git hooks.

If you must use the updated version of the SDK, you will likely have to go through a process of manually including each missing dependency.

TLDR; use the Lambda built-in aws-sdk packages, don't specify your own versions

[jpgrace]

Thanks @yenfryherrerafeliz and @linbasil. Moving the @aws-sdk/client-sqs dependency to devDependencies fixed my issue. 🍻

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.