feat: added Rolldown support to NodeJSFunction

[robert-pitt-foodhub]

Issue # (if applicable)

Closes #35776, #32723

Reason for this change

Currently, NodejsFunction only supports esbuild as a bundler for Lambda code. This PR adds support for Rolldown, a fast Rust-based bundler with an API compatible with Rollup, giving users an alternative bundling option while maintaining full backward compatibility.

Description of changes

This PR introduces Rolldown as an alternative bundler for the aws-lambda-nodejs package without introducing any breaking changes.

Key Changes:

1. Type Definitions (lib/types.ts):

   • Added Bundler enum with ESBUILD (default) and ROLLDOWN options
   • Extended BundlingOptions interface with:
     • bundler?: Bundler - Allows users to select their preferred bundler
     • rolldownVersion?: string - Specify Rolldown version for Docker bundling
     • rolldownArgs?: { [key: string]: string | boolean } - Pass custom CLI arguments to Rolldown
   • Updated documentation for bundler-specific options (e.g., keepNames, metafile, sourcesContent, target are esbuild-only)

2. Bundling Logic (lib/bundling.ts):

   • Added Rolldown version constants (ROLLDOWN_MAJOR_VERSION = '1', ROLLDOWN_DEFAULT_VERSION = '1.0.0-beta.44')
   • Implemented Rolldown installation detection and caching
   • Created createRolldownCommand() method to generate Rolldown CLI commands
   • Refactored createBundlingCommand() to conditionally use esbuild or Rolldown
   • Updated Docker image building to include Rolldown version
   • Updated local bundling provider to support both bundlers

3. Docker Support (lib/Dockerfile):

   • Added Rolldown installation to the bundling Docker image
   • Both esbuild and Rolldown are now installed globally in the image

4. Documentation (README.md):

   • Added comprehensive "Using Rolldown as an Alternative Bundler" section
   • Included usage examples and notes on bundler-specific options
   • Documented bundler selection and configuration

5. Testing:

   • Created test/bundling-rolldown.test.ts with comprehensive unit tests covering:
     • Docker bundling with Rolldown
     • Minification and source maps
     • External modules
     • Custom Rolldown arguments
     • ESM format support
     • Local bundling
     • Define, banner/footer, loaders
     • Default behavior validation
   • Created integration test test/integ.rolldown.ts with multiple test cases
   • Added integration test handler test/integ-handlers/rolldown-handler.ts

Design Decisions:

• Backward Compatibility: esbuild remains the default bundler (no breaking changes)
• Similar API: Rolldown implementation mirrors the esbuild implementation pattern
• Shared Options: Most bundling options work with both bundlers (minify, sourceMap, externals, etc.)
• Bundler-Specific Options: Options that are esbuild-only are clearly documented
• Conditional CLI Generation: Separate command builders for each bundler to maintain clean separation

Alternatives Considered:

• Creating a separate package for Rolldown support (rejected: would fragment the API)
• Making Rolldown a peer dependency (rejected: complicates installation)
• Using a plugin system (rejected: over-engineering for this use case)

Describe any new or updated permissions being added

No new or updated IAM permissions are required for this change.

Description of how you validated changes

Unit Tests:

• Added comprehensive unit tests in test/bundling-rolldown.test.ts (11 test cases)
• Tests cover Docker bundling, local bundling, all CLI options, and default behavior.
• All existing esbuild tests continue to pass, ensuring no regressions

Integration Tests:

• Created test/integ.rolldown.ts with 4 integration test scenarios:
  • Basic Rolldown bundling with minify and sourcemap
  • Rolldown with external modules
  • Rolldown with ESM format
  • Rolldown with custom arguments and define
• Created test handler that uses modern ES features to verify bundling works correctly

Manual Testing:

• TODO

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

[aws-cdk-automation]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[mrgrain]

Alternatives Considered:
Creating a separate package for Rolldown support (rejected: would fragment the API)

I disagree with this assessment. In types.ts you now have introduced a bunch of options that only work under certain conditions. To me that's the definition of fragmentation. Wouldn't a separate package provide a much cleaner interface and stricter separation of concerns?

[robert-pitt-foodhub]

Hey @mrgrain

Thanks for taking the time to review the PR, I agree that there is some fragmentation still, however I think I can align them better

for example, the fields that are currently fragmented are

1. keepNames - There is an option in rolldown for this option which I can correct and align
2. target - Looking at the supported list of targets with esbuild, they are a mixed between browser and server runtimes, is it expected that target here would only be used for lambda runtimes and not browsers?
3. metafile - Cannot seem to find an option on rolldown for this
4. sourcesContent - Cannot seem to find an option on rolldown for this either

Would aligning the keepNames and target fields better align with your expectations ?

Thanks