Cannot find module 'node:http` on AWS Lambda v14

[pawelgrzybek]

Upgrade from version 3.0 to 3.1 produces a Runtime.ImportModuleError: Error: Cannot find module 'node:http on AWS Lambda runtime.

Screenshots

Your Environment

software	version
node-fetch	3.1
node	14

Additional context

Looks like node: prefix for imports added as part of #1346 causes this issue. I am happy to submit MR with a revert of this one, but I need to understand the reason why this prefix has been added here on the first place. Can you suport me on this one please @dnalborczyk ?

[jimmywarting]

https://nodejs.org/dist/latest-v17.x/docs/api/esm.html#node-imports

We are targeting node v12.20 and above. and node: prefix got supported in 12.20 for esm syntax, but not for require syntax until v14.18

[pawelgrzybek]

@jimmywarting In this case it looks like it is going to break for all CJS users between versions 12.20 (your target version) and 14.8. In my case looks like AWS runtime is <14.18.

[martin-dimitrov13]

Same here, locking at 3.0.0 until a fix is deployed.

[pawelgrzybek]

@martin-dimitrov13 thats done

#1368

[jimmywarting]

Are you running some job to compile the source to cjs?

[pawelgrzybek]

@jimmywarting, the build part is happening on AWS side. I use CDK framework and I send .ts files to AWS. I believe it is compiled using esbuild under the hood (not 100% confidence about this one).

https://aws.amazon.com/cdk/

[LinusU]

In this case it looks like it is going to break for all CJS users between versions 12.20 (your target version) and 14.8. In my case looks like AWS runtime is <14.18.

Hmm, but version 3.x of node-fetch is ESM only so we don't actually support CJS at all.

It seems like in this case there is a build step that turns import into require, but still keeps the node: prefix. I was unable to find what transpiling process that AWS CDK uses from a quick glance...

[pawelgrzybek]

Does node-fetch actually take any advantage of node: prefix at the moment? If no I personally see no reason of keeping it just for the sake of new syntax.

[dnalborczyk]

I need to understand the reason why this prefix has been added here on the first place. Can you suport me on this one please @dnalborczyk ?

it's to distinguish between userland modules and node.js built-in modules. it serves as a namespace.

[dnalborczyk]

@jimmywarting In this case it looks like it is going to break for all CJS users

this is an esm module, I would argue it's already "broken" for cjs users.

[pawelgrzybek]

@dnalborczyk thank you for explanation. Today I learned about node: prefix.

I will leave it for people smarter than me to decide if it is useful in context for this project or not. I just wanted to report because it broke my project and can potentially affect many more.

Wait a sec, because the 3.0 version worked just fine and 3.1 collapsed on some runtimes, shouldn't that be a major release?

[dnalborczyk]

the build part is happening on AWS side. I use CDK framework and I send .ts files to AWS.

very unlikely. I'm fairly certain the build is happening locally on the dev side.

I believe it is compiled using esbuild under the hood (not 100% confidence about this one).

aws.amazon.com/cdk

you are very likely down leveling to commonjs, you should check your tsconfig.json module setting. aws lambda does not support esm modules yet.

you can see it in the stacktrace, Userfunction.js throwing: https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/blob/c31c41ffe5f2f03ae9e8589b96f3b005e2bb8a4a/src/utils/UserFunction.ts#L75 handlers are being cjs required.

[pawelgrzybek]

very unlikely. I'm fairly certain the build is happening locally on the dev side.

@dnalborczyk you are right. It is part of a deployment and it is compiled locally using esbuild.