aws
aws_lambda_nodejs: exclude node_modules option from sourcemaps
Describe the feature
Excluding sourcemaps and shipping them to your third-party provider is great, but for Lambdas using CloudWatch, you have to include them to get meaningful traces.
It is possible to exclude node_modules sourcemaps to drastically save on final zip size.
Use Case
Reduce lambda cold starts without sacraficing on the sourcemaps for your own code, which should be enough to properly debug in 90% of the cases.
Proposed Solution
This PR shows an improvement from 34K to 2.2K for the sourcemap file.
Esbuild plugins do not work in sync mode, only async. I know we can not do async work in the try bundle, but there are ways around it 😅, using deasync. Yes this is a controversial package and should not be used in any production runtime code, but seeing as this happens on build time, I feel it is an acceptable "risk" worst case the user can disable the flag if there is really an issue.
You can see it in action in this Gist I proposed some time ago.
Other Information
No response
Acknowledgements
- [X] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
CDK version used
Environment details (OS name and version, etc.)
Thank you for your feedback. Feel free to submit your PR when it's ready and we welcome any further discussions.
I looked into it and I don't think this can be done easily without a considerable rewrite. This is because this package runs the esbuild command natively instead of using the esbuild API as in my example and we need to use the API to use plugins.
If done, then my premise (below) is wrong, this change will not be as isolated as I hoped.
Yes this is a controversial package and should not be used in any production runtime code, but seeing as this happens on build time, I feel it is an acceptable "risk" worst case the user can disable the flag if there is an issue.
So I believe we can close this. I will be publishing an external package for this, something that does not have docker bundling as an option and can use esbuild plugins. I'll also be including this https://github.com/aws/aws-cdk/issues/28087 in that package, so I don't know if we want to close it as well.
Aside from the cold start penalty, the biggest issue with leaving large sourcemaps like this in is the extra RAM usage. We've seen cases where an error being thrown causes the source map resolution to trigger and crash the entire process with an out of memory error. This makes enabling sourcemaps actually give you worse visibility into errors, since your actual error will never get logged now. We've had to allocate extra RAM or only run some sourcemaps on beta stages to mitigate this. It would be great if there was proper first-class support for this.
