Feature request: build as esmodule

[flochaz]

Description of the feature request

Problem statement
Powertools is packaged as commonJS which does not give the capability to javascript developers to use esmodule import syntax and feature.

Summary of the feature
Now that AWS Lambda support es module import it might worth generating esmodule.

Code examples

Before:

const { Tracer } = require('@aws-lambda-powertools/tracer');

After:

import { Tracer } from '@aws-lambda-powertools/tracer';

Benefits for you and the wider AWS community
See https://aws.amazon.com/blogs/compute/using-node-js-es-modules-and-top-level-await-in-aws-lambda/ for more details ...

Additional context
slack channel discussion

Related issues, RFCs

#490

[saragerion]

Thanks @flochaz for opening this issue! If I look at the AWS SDK v3, this is how @trivikr and the team handles it:

1. They transpile the TS code three times, once for CommonJS, once for ES6 and once for the types. To achieve this, they use 2 tsconfig files: tsconfig.cjs and tsconfig.es.
2. In their docs, they use both import styles in their examples: https://github.com/aws/aws-sdk-js-v3/tree/cc17fa2296654192d2a9c2cf567d2ce58d81d15b/lib/lib-dynamodb#constructor.

Full example for the DynamoDB client:
https://github.com/aws/aws-sdk-js-v3/tree/cc17fa2296654192d2a9c2cf567d2ce58d81d15b/lib/lib-dynamodb

---

Personally, I think that right now supporting both CommonJS and ES6 is not a high priority, but a nice to have that would definitely improve the dev experience. I would like to see a small proof of concept but I don't think this is something we should prioritize for the production ready milestone.
(Maybe some folks from our community can help out in the future?)

[dreamorosi]

If we want, at least for now, make sure that the three core utilities available (Logger, Metrics, and Tracer) all advance at the same pace, the main dependency for Tracer (aws-xray-sdk-node) constitutes a major blocker for this effort as it currently doesn't support ESM bundling.

Given that our main focus at the moment is to bring these utils to a production ready status. Marking this issue as blocked and on-hold till further notice.

[bestickley]

I'm only using @aws-lambda-powertools/logger and would really appreciate an ESM build even if aws-xray-sdk-node is blocking @aws-lambda-powertools/tracer. Thank you!

[dreamorosi]

Recap of the status and actions required before being able to move forward with this:

While we acknowledge that there's an option to independently support ESM on some utilities while leaving others only with CJS support, we are still keen in dedicating some effort in investigating ways to bring ESM support for all utilities. We believe that doing so would result in a less confusing developer experience for users, since they wouldn't have to check which utility supports what.

At the moment, before starting to work on the feature we need to resolve the following topics:

• Should we support both CJS and ESM? What are the tradeoffs in doing so? (i.e. package size, cold start, etc.)
• If we were to support both, what would be the impact on our CI/CD and release processes?
• If we were to change from CJS to ESM, or support both, would there be differences in how users install, import, use the libraries?
• If we were to bundle exclusively to ESM, would the utilities still work on Lambda functions that don't use ESM?

The resolver for this issue will have to primarily investigate the scope of the changes and propose options to move forward along with considerations on the tradeoffs for each option. Ideally, each solution/option should also propose high-level examples of where the changes would be (i.e. tsconfig.json, build system, release process, etc.), as well as detail any changes in the public API (i.e. will there be changes in how users import the libraries?).

If anyone is willing to take this on, please leave a comment below before starting to work on it.

[dreamorosi]

All the modules have now been converted to esm + cjs on the feat/v2 branch.

In the next days I'll work on creating an alpha release channel so that you can start testing the new version and let us know if there's any issue with the way things are built.

Once again, a huge thank you to everyone who interacted with the issue and helped push this forward - especially @shdq and @antstanley.

[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.