(aws-lambda-nodejs): support additional esbuild configurations(main-fields)

Description

Currently only a subset of esbuild configs are exposed to users via BundlerOptions:https://github.com/aws/aws-cdk/blob/29039e8bd13a4fdb7f84254038b3331c179273fd/packages/%40aws-cdk/aws-lambda-nodejs/lib/types.ts#L6

However there are much more configs supported by esbuild: https://esbuild.github.io/api/

A good example is main-fields: by default esbuild will prefer main entry of package.json for Node.js app. However, this is usually the entry point for CommonJS module, thus, esbuild cannot treeshake it well. If we specify the esbuild to prefer the module entry point, the function bundle can be reduced more with tree shaking.

Use Case

If main-fields is specified for AWS SDK v3, the SDK size can be further reduced by more than 50% with tree shake enabled.

Proposed Solution

Even though this request is asking main-fields config explicitly, CDK can also expose interface for arbitrary esbuild config. Just like buildArgs for the image building step: https://github.com/aws/aws-cdk/blob/29039e8bd13a4fdb7f84254038b3331c179273fd/packages/%40aws-cdk/aws-lambda-nodejs/lib/types.ts#L210

There are 2 alternatives for it:

1. Expose additional options in BundlingOptions like { esbuildConfigs: { [key: string]: string } }. This alternative may requires validating the duplicated options with other existing esbuild configs.
2. Expose a path option for users to provide custom esbuild.js file, which calls the esbuild JS API. This will ignore all other esbuild configs. The advantage is that it supports all the future esbuild configs.

Other information

No response

Acknowledge

• I may be able to implement this feature request
• This feature might incur a breaking change

[alexbaileyuk]

Updated the PR and left my thoughts on the comment in question.

Fantastic. I see it has been merged as well which is great. Thanks for the quick turn around!

[ryparker]

Thanks for the ping. I’ll give this a look.