[lambda-nodejs] Accept a user-defined bundler in NodejsFunctionProps

I’d like to be able to pass in an instance of cdk.ILocalBundling into NodejsFunctionProps rather than having to use the default implementation

Use Case

I’ve created a Webpack implementation of cdk.ILocalBundling and would like to use this rather than parcel or the upcoming esbuild without losing the extra functionality of NodejsFunction.

Proposed Solution

I’d like to be able to call NodejsFunction like this:

new NodejsFunction(
      this,
      "getRegistrationFunction",
      {
        entry: "src/lambda/get-registration/index.ts",
        handler: "handler",
        bundler: webpackBundler
      }
);

Where webpackBundler is an instance of cdk.ILocalBundling. The webpackBundler would then get passed into the Bundling class to be used when it calls lambda.Code.fromAsset, that way it can keep all the benefits of both NodejsFunction and Bundler

Other

• 👋 I may be able to implement this feature request If this is approved, I’d be happy to try and create a PR for it

---

This is a 🚀 Feature Request

[Garethp]

So I understand the desire to get people to contribute to esbuild rather than just passing over it, but I think that misses the main point of what I was hoping for. For our team, we’d rather not maintain two different build systems over our TS stack (Front-end and backend), and we’d also rather not have our build system dictated by an upstream dependency.

We’ve built our webpack config to work for us with various plugins that help to optimize our output and debugging tools for our use-case (Ignoring certain parts of TypeORM, having the right type of sourcemaps, having the right bundle analyzers when we want it). When we look at a tool like NodeJSFunction it looks fantastic but being locked into a specific build system is a definite downside.

That downside was even more prominent that when it came to trying to use it, I was unable to get parcel 2 working on our codebase and then it was decided to that NodeJSFunction would switch to esbuild instead. Not being able to use our existing build system and not having the certainty that NodeJSFunction will use the same build system one year down the line as it does now is a fairly large issue when it comes to adopting it.

In the end it’s less about whether the implementation of esbuild could work for us with some tweaks and changes, but more about not needing to change our build system just to use NodeJSFunction in the first place.

[nbaillie]

@jogold @Garethp, Bring your Own Build System would be useful for me for the reasons that Garethp has outlined. It would be good to have a layer of flexibility in the build system choice, letting other keep with their currently selected build system and to protect and plan for evolution and emerging/future build systems.

However, that said what you have done with lamda-nodejs is a fantastic addition to CDK especially when paired with cdk-pipelines, it takes a way a great deal of pain.