[lambda-nodejs] Accept a user-defined bundler in NodejsFunctionProps
See original GitHub issueI’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
Issue Analytics
- State:
- Created 3 years ago
- Reactions:6
- Comments:12 (8 by maintainers)
Top Results From Across the Web
interface NodejsFunctionProps · AWS CDK
Where to place the network interfaces within the VPC. allowAllOutbound? Type: boolean (optional, default: true). Whether to allow the Lambda to ...
Read more >@aws-cdk/aws-lambda-nodejs - npm
This is useful when working with native dependencies or when esbuild fails to bundle a module. new lambda.NodejsFunction(this, 'my-handler' ...
Read more >AWS CDK - aws-lambda-nodejs Module (updated)
Whenever you run a cdk deploy or cdk synth , this module will bundle your Lambda functions and output them to your cdk.out...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.
@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.