feat(Templates): Package lambdas individually in aws-nodejs-typescript

[adriencaccia]

Opt for individual lambda packaging, resulting in:

• faster build times with large projects
• smaller bundle size for each lambda

[codecov]

Codecov Report

Merging #10106 (35e5873) into master (1a528c2) will not change coverage.
The diff coverage is n/a.

❗ Current head 35e5873 differs from pull request most recent head f8249e4. Consider uploading reports for the commit f8249e4 to get more accurate results

@@           Coverage Diff           @@
##           master   #10106   +/-   ##
=======================================
  Coverage   85.26%   85.26%           
=======================================
  Files         334      334           
  Lines       13638    13638           
=======================================
  Hits        11628    11628           
  Misses       2010     2010           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1a528c2...f8249e4. Read the comment docs.

[mnapoli]

Thanks! I'm wondering if this is something we want to have by default in the templates? Splitting the artifacts is usually a more advanced use case (not the one we want to use when getting started with serverless), right?

[fredericbarthelet]

@adriencaccia did some fact checking on this to make sure it is a good default to offer.

Smaller lambda artifact has benefits on performance, wether your project includes a single lambda or a 1000. Multiple factors impact lambda artefact size: bundler, minifying the code, tree shaking dependencies, individual packaging, exclude specific dependencies from your build (like aws-sdk)...

Individual packaging has impact as soon as your project includes at least 2 lambdas (so even simple use cases are affected). Packaging individually mainly impact build time on your machine before shipping artefacts.

In order to ensure individual packaging does not impact badly packaging experience before deployment, and considering a project with 100 lambdas on average weighting in 3M, we have the following results:

The key to have a good packaging experience when using individual packaging is to ensure esbuild concurrency is not unlimited, therefore adding the concurrency: 10 configuration in this template.

I'd be in favor of having such configuration from the beginning, but maybe I'm missing something here. Do you know of any particular issue that might arise from individual packaging ?

[mnapoli]

What I meant is that templates are meant to kickstart new users with serverless, so they should cover simpler use cases (and they should be simple to understand). I don't see a reason to make that specific template different from the others.

And I understand the benchmark with 100 functions, but this isn't what new projects created from templates contain :p

More generally, I think we could have the same discussion about any advanced feature (should it be part of the template or not). And I think the question boils down to:

• is that feature a universal best practice/requirement
• or is it a feature that makes sense in specific scenarios

I'd say packaging individually makes sense in some scenarios (users have many functions), it's not a universal feature (else I'd even argue it should be the Framework's default).

[mnapoli]

After discussing it live with @fredericbarthelet, he managed to convince me 😄

To sum up: this change is a net improvement in all cases for that template specifically.

More details:

• why in this template specifically? because it uses esbuild, so parallel building is always faster
• benefits appear even with only 2 functions (because packaging is so fast) and also is beneficial with 100 functions (unlike webpack, the esbuild plugin manages concurrency correctly)
• benefits include: packaging faster (again, that's because of esbuild) and cold starts are faster

As such, I'm 👍 with merging this, it's only an improvement for users. The only downside is a slight inconsistency with other templates.

[pgrzesik]

Thank you @adriencaccia 🙇

[aardvarkk]

@adriencaccia One downer with this new template is that esbuild does not support Decorators (and doesn't ever plan to). The project I'm working on uses TypeORM which is fairly reliant on them. I tried to upgrade our setup to this new esbuild-based template (I would love to package our lambdas individually), but eventually hit a wall when I got it all running and realized our functions couldn't load the metadata for our TypeORM classes and thus would not run.