Description
Summary
Despite us shipping both CJS and ESM builds to npmjs, our codebase runs TypeScript primarily as commonjs. This is a relic of the v1 codebase that was never updated.
Some packages in the ecosystem - ironically including us - are starting to leverage sub-path exports to provide granular exports to different parts of the package. This is what Zod is doing to ship v3 alongside v4, respectively under zod/v3 and zod/v4.
While we haven't decided yet when we're going to upgrade to Zod v4, we will probably have to update the imports in our codebase from using zod to use zod/v3 sometime soon. Currently Zod aliases zod to v3, but once that changes things might start breaking. Updating the imports also helps customers immediately understand which version we support.
In order for us to do this, we need to change the module resolution config in the tsconfig.json file, and the option we want to use requires ESM (others are compatible with CJS but since we're switching we might as well switch to the best config).
Because of this, we should update our tsconfig.json files accordingly.
Why is this needed?
So that we can facilitate the migration to newer module schemes (i.e. #3951), and in the future potentially run our unit tests without having a build step.
Which area does this relate to?
No response
Solution
Switch the tsconfig.json (currently CJS) and tsconfig.esm.json to tsconfig.cjs.json and tsconfig.json (to become ESM).
Acknowledgment
- This request meets Powertools for AWS Lambda (TypeScript) Tenets
- Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status