aws-lambda-nodejs: Default entry finding fails when defining file starts with "file://"

[jonbarksdale]

Describe the bug

Attempting to create a lambda with NodejsFunction, which should auto find the handler based on the defining files path.

I get an error that looks like this:

Error: Cannot find handler file file:///Users/stack.handler.ts, file:///Users/<path>/stack.handler.js or file:///Users/<path>/stack.handler.mjs

where the middle of the path has been replaced with for brevity and privacy.

This implies the paths being checked start with "file://", which I've tested and does not work with Node 16.13.1.

Those paths are produced from this function, which I believe is incorrect.

This is running on macos 12.5, with the a fore mentioned version of nodejs.

Expected Behavior

I expected it to find the file, as the path was correct without the file:// prefix.

Current Behavior

Error: Cannot find handler file file:///Users/stack.handler.ts, file:///Users//stack.handler.js or file:///Users//stack.handler.mjs

Reproduction Steps

Create a lambda function using NodejsFunction with no entry parameter specified, and synthesize.

Possible Solution

callsites() produces paths that start with file:// when they are local files, and findDefiningFile doesn't scrub the path. Maybe make findDefining file remove the prefix when it's file://

Additional Information/Context

No response

CDK CLI Version

2.37.1 (build f15dee0)

Framework Version

No response

Node.js Version

16.13.1

OS

macos 12.5

Language

Typescript

Language Version

4.7.2

Other information

No response

[corymhall]

@jonbarksdale I've tested this out on the same node version and macos version and have not been able to reproduce the issue. Can you try reproducing on a fresh project and let me know if you can reproduce?

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[okko]

Workaround: sindresorhus/callsites#18 (comment)

Node 16.17.0 was expected to fix this according to the callsites issue 18 above, nodejs/node#39787 but I'm experiencing still the same with Node 16.17.0 when using ESM.

[okko]

@corymhall To reproduce please see https://github.com/okko/aws-cdk-esm-file-urls-reproduce

[corymhall]

@okko thanks for the additional info and the reproduction! I think I'm fine with the solution that you suggest, i.e. adding replace('file://', '').

We would definitely accept contributions!

[jonbarksdale]

Thanks @okko, appreciate you stepping in with the reproduction.

[okko]

Workaround until issue is resolved in aws-cdk:

const handler = new lambdaNodejs.NodejsFunction(scope, functionId, {
  entry: new URL(import.meta.url.replace(/(.*)(\..+)/, '$1.' + functionId + '$2')).pathname, // https://github.com/aws/aws-cdk/pull/21802#issuecomment-1249940400
})

[e3dio]

So the default way to use Node.js Lambda function does not work, and no progress has been made for 11 months to fix it? I am getting same error

[nickej]

Is entry: new URL(import.meta.url.replace(/(.*)(\..+)/, '$1.' + functionId + '$2')).pathname still the best workaround for this issue? It looks lite the PR by @okko was abandoned. I could look into making a new PR with the replace('file://', '') fix since this seems to still be an issue.

[okko]

Yes, it is still the best workaround. I appreciate if you @nickej want to continue with the code from https://github.com/aws/aws-cdk/pull/21802/files. At the time it was blocked due to no tooling for ESM in the tests and @TheRealAmazonKendra requiring integration tests. The NodeJSFunction has been broken for ESM functions for over 2 years.

[nickej]

Ok, thanks for confirming @okko. I've worked a bit in my own fork on this but unfortunately it looks like there is still no easy way to run integration-tests using ESM. At least not something I found. Writing the test itself is easy enough but setting it up so that the code under test will be generated towards ESM is not something I had any luck with.

I have asked for support in the cdk-dev Slack.

[Ys-Zhou]

It has been 2 years. Since node18 will be EOL in monthes, I really think cdk should support ESM by default and give a flag to anyone who wants to keep on CJS.