Skip to content

4.0.1 Does Not Resolve Modules Relative to Working Directory #184

@ptefft-bizequity

Description

@ptefft-bizequity

Dockerfile

I have a Dockerfile that has previously worked with RIC 3.3.0, following the conventions described in the README for the 22.x branch. It does not work on 4.0.1 I think because 4.0.1 fundamentally doesn't care about the current working directory anymore in favor of the LAMBDA_TASK_ROOT environment variable.

3.3.0 Behavior

In 3.3.0, (nodejs22.x branch), bin/index.mjs pulls the current working directory and uses that as the app root.

const appRoot = process.cwd();
const handler = process.argv[2];
  
console.log(`Executing '${handler}' in function directory '${appRoot}'`);
await run(appRoot, handler);

This works with the conventions on the 22.x README, which encourage me to put the handler at a relatively arbitrary FUNCTION_DIR that we also set as the working directory.

I wasn't able to find LAMBDA_TASK_ROOT in the source code on this branch.

4.0.1 Behavior

When moving to 4.0.1 (nodejs24.x branch), we get this error on AWS Lambda:

2026-01-27T19:25:52.402Z	-	ERROR	Init Error 	
{
    "errorType": "Runtime.ImportModuleError",
    "errorMessage": "Error: Cannot find module 'lambda'\nRequire stack:\n- /function/node_modules/aws-lambda-ric/index.mjs",
    "name": "Runtime.ImportModuleError",
    "stack": [
        "Runtime.ImportModuleError: Error: Cannot find module 'lambda'",
        "Require stack:",
        "- /function/node_modules/aws-lambda-ric/index.mjs",
        "    at loadModule (file:///function/node_modules/aws-lambda-ric/index.mjs:575:13)",
        "    at async UserFunctionLoader.load (file:///function/node_modules/aws-lambda-ric/index.mjs:506:20)",
        "    at async createRuntime (file:///function/node_modules/aws-lambda-ric/index.mjs:1219:52)",
        "    at async ignition (file:///function/node_modules/aws-lambda-ric/index.mjs:1635:21)"
    ]
}

I don't see anything that tries to resolve the module against the working directory. It seems to rely only on the LAMBDA_TASK_ROOT environment variable.

24.x Docs

The README for the 24.x branch covers building a Lambda image using an arbitrary-ish base Docker image here.

These docs continue to use an arbitrary FUNCTION_DIR and don't seem to include any steps for copying handler code into the image, which leaves me with some questions.

Questions

Is this behavior change expected/intentional?

If it is, I have the following questions as someone building an image from scratch, and we may want to clarify the README:

  • As someone building an image, should I set a LAMBDA_TASK_ROOT variable pointing to where I put the handler module as the official images do (e.g. public.ecr.aws/lambda/nodejs:22)?
  • Is it important or helpful for me to use /var/task as LAMBDA_TASK_ROOT or is it arbitrary?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions