Feature request: minimize size of the production lambda-layer or published npm package

[michaelbrewer]

Description of the feature request

Try to keep the production deployed node_modules, without loss of functionality

Related issue: #419 (comment)

Problem statement

Keeping the published npm package as lean as possible will benefit all users in terms of cold start.

Summary of the feature

• strip unneeded files (tests, .d.ts)
  • this is not needed for runtime
• strip unneeded dependencies or non-aws managed/secured (eg: @types/aws-lambda and lodash.clonedeep ?)
  • This is a security risk
  • It bloats the library when not needed (eg: for createChild we can also use setOptions( from the original or v8 built in deserialize / serialize)
  • some upstream bugs needs to be fixed (Incorrect types for lambda authorizer event DefinitelyTyped/DefinitelyTyped#51120)
  • It is often easier to add a dependency than remove
  • it is harder for people to vendor powertools features
  • or not even referenced within the project types/aws-lambda.
• minify if not already

Code examples

NA

Benefits for you and the wider AWS community

Faster execution, deployments (especially if there are published lambda layers).

Describe alternatives you've considered

Using modclean, minify-all and node-prune and documentation on recommendations to reduce cold starts

Additional context

• https://github.com/ModClean/modclean
• https://github.com/tj/node-prune
• https://tsh.io/blog/reduce-node-modules-for-better-performance/
• https://aws.amazon.com/blogs/developer/how-we-halved-the-publish-size-of-modular-aws-sdk-for-javascript-clients/

Related issues, RFCs

• Feature request: reduce npm_modules size  #419

[saragerion]

Thanks for creating this issue.
Good news are that this unit of work is already on our radar and we are looking at several ways in which we can iteratively reduce the size while also keep it under control in the future. Possible iterations on this effort include some of the tips you mention, and also tree shaking and safety nets in our CI/CD pipelines.

Our team will definitely work on this as part as the production-ready milestone.

[michaelbrewer]

i am sure it makes sense once their is stability in the apis, integration and unit testing :). I am sure the community would really appreciate this level of effort. :)

Another useful thing to consider is building some benchmarking to track for regressions.

[saragerion]

Another useful thing to consider is building some benchmarking to track for regressions.

100%. Related comment: #398 (comment)

[dreamorosi]

We have just release Lambda Layers and have implemented automation to measure the impact of each PR.

I will be closing this issue for the time being as the size of the utilities is still within more than reasonable bounds.

Will revisit the topic once we implement benchmarks.

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