Bug: Middy requires special flag in tsconfig.json to be imported as esm

[asenousy]

Bug description

when using middy i get the following error TypeError: core_1.default is not a function

Possible Solution

updating the tsconfig.json with "esModuleInterop": true solved the problem as suggested in middy's github Issue middyjs/middy#203

Environment

• Powertools version used: 0.2.0
• Packaging format (Layers, npm): npm
• AWS Lambda function runtime: node v14

[dreamorosi]

Hello @asenousy, thanks for opening this issue. Just for context we are using that same config in the tsconfig.json files of our packages (i.e. here). We'll be looking at this and get back to you.

[willfarrell]

In middy v3 (alpha already released) we plan to make esm the default, possibly making this a non-issue.

[peledni]

A workaround for those of us who can't use "esModuleInterop" : true in tsconfig:

import * as MiddyTypes from '@middy/core';
const middy = require('@middy/core') as typeof MiddyTypes.default;

[ijemmy]

Put this on-hold as this will be solved when we upgrade to middy v3.

@saragerion I wonder if we should make this note in our doc? (for all utils, in middy tab). On the other hand, this is middy specific and middy v3 will be released when NodeJS16 is supported in Lambda. We can wait to just upgrade once.

I'm inclined to wait and upgrade as we aren't out of beta yet. What's your thought?

[willfarrell]

Using ESM by default in Middy was the plan. However ...

(a) Recent discoveries that Lambda with ESM cannot access node_modules pre-bundled in the runtime or shared in a lambda layer has made us stop and rethink. This isn't documented anywhere that I know of :(. I've reported this regression to AWS Support and was told to use v3 of the SDK instead.

(b) We would consider migrating to using v3 of the SDK (I even tried a year ago), however, RDS.Signer is not implemented yet (aws/aws-sdk-js-v3#1823 @AllanZhengYP). Using v3 of the SDK would increase lambda bundle size compared to v2 of the SDK. I would suggest AWS pre-bundle all v3 packages in the runtime (aws/aws-sdk-js-v3#2149), but this wouldn't help with ESM support because lambda handlers wouldn't be able to access them anyways (a) 🤷

(c) Even if (a), or (b*2) are resolved, the X-Ray SDK using dynamic require breaks when using ESM (aws/aws-xray-sdk-node#482 @NathanielRN).

Based on the current state of ESM support from AWS outlined above, the new plan for middy@3 will be to continue providing CommonJS for another year sadly. We're going to wait (2-3 week) and see if ((a OR b*2) AND c) are resolved before making a final decision and mint a beta release.

Cross posted from: middyjs/middy#584

cc @lmammino

[dreamorosi]

At the moment this project does not guarantee support for ESM builds, we have a dedicate issue to track this topic which you can subscribe to get updates: #521

Closing this issue.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.