AWS killed loading ES modules using require()

[pmosconi]

Hi,
Starting with Lambda runtime version nodejs:22.v35, that corresponds to NodeJS v22.14.0, AWS has decided to stop supporting the ability to require ES modules, so the approach suggested in the upgrade docs (
https://middy.js.org/docs/upgrade/5-6 ) for the adoption of Middy in CommonJS applications is not viable any more.

I opened a ticket with support and they answered saying the feature is still experimental and they decided to stop supporting it.
This is a bit counter-intuitive to me because the feature originally required the use of --experimental-require-module CLI flag and since v22.2.0 the flag is no longer necessary.
I am quite disappointed with how this has been handled, much I don't think there's much to be done.

So, heads up to all who potentially have the same issue and update the docs.

[willfarrell]

Thanks for sharing, very sad to hear. I saw this feature as critical path in allowing teams to more easily migrate to ESM, all while reducing the workload on the js foss community as a whole. Hopefully AWS will reconsider.

cc @dreamorosi @lmammino

[dreamorosi]

Hi, thanks for flagging this.

I'll try reproducing the change and check with the team to see what's the latest.

Once I have more to share I'll do so here.

[dreamorosi]

In the meantime, while not ideal and as a stop gap solution, I suggest you to pin the runtime version to a previous version so that your workload can continue working.

[willfarrell]

@dreamorosi thanks for following up on this.

[dreamorosi]

@pmosconi - would you mind emailing me at aws-powertools-maintainers@amazon.com with the case ID you mentioned above?

[pmosconi]

In case anyone needs, here's how to pin runtime version:
aws lambda put-runtime-management-config --function-name <arm-function> --update-runtime-on Manual --runtime-version-arn "arn:aws:lambda:eu-west-1::runtime:0e9cb0254cfdee1d92f17152f250572f73e1639502454774e594375792782241"
aws lambda put-runtime-management-config --function-name <x86-function> --update-runtime-on Manual --runtime-version-arn "arn:aws:lambda:eu-west-1::runtime:f494bf5385768c1a5f722eae90b6dd3d343c96ba7ec22b34f5c819e3e8511722"

[willfarrell]

Closing but will keep pinned. @dreamorosi is there anything from AWS that you can share on the future of this feature?

[dreamorosi]

Hello, sorry for the delay here - I should've reported back earlier.

I can confirm that the feature - which is still marked as experimental in this version of the Node.js - was removed because it carried a performance penalty that would have affected all customers, even those not using it.

Lambda has disabled this feature by implementing the --no-experimental-require-module flag in the bootstrap script of the managed Node.js runtime.

Because of this, assuming you can't migrate to ESM or move to a dependency that still supports CJS:

• continue using the pinned version of the managed runtime as long as it's available
• create a custom bootstrap script (aka custom runtime) and enable the Node.js feature
• work with a custom import/require similar to what described here

[willfarrell]

Thanks for the follow!

[pmosconi]

@dreamorosi , any idea what are the plans for node v.24 lambda runtime? I know work is underway.
Thanks

[dreamorosi]

I don't know if this feature will be enabled in the new runtime, but I expect the team to take the same data driven approach based on performance and whether the feature is still experimental or not.

I know the runtime team is actively working on Node.js 24 and have been soliciting feedback around other areas that have gathered a decent amount of interest from the community (i.e. aws/aws-lambda-nodejs-runtime-interface-client#137) so I'd encourage you to open an issue there.

This way the team can answer directly as well as see if other customers also want this enabled.