Jonathan Tuliani

Defining Lambda function code inline within a CloudFormation template is currently only supported for Node and Python runtimes, as described in our documentation at https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-lambda-function-code.html. We do not currently have...

Please note AWS Lambda now supports Java 17: https://aws.amazon.com/blogs/compute/java-17-runtime-now-available-on-aws-lambda/

This is a consequence of the underlying CloudFormation support for inline Lambda functions. Please see https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/1420 for updates.

I like the idea of a warning as a last resort, but I would still prefer to see the CRLF fixed. I think we're over-indexing on preserving the existing experience,...

@lpsinger Thanks for raising this. It's a good suggestion. Question: do you prefer to be able to specify .mjs vs .cjs explicitly, or would it be better/acceptable for Lambda/CloudFormation to...

@lpsinger @luizcarlosrodrigues @trparchman @abiodunakande To help us prioritize, it would be useful if you can explain the impact of not supporting ES modules in inline functions in CloudFormation templates. Is...

We are considering changing the default file name from ```index.js``` to ```index.mjs``` starting from the Node.js 22 runtime. Earlier runtimes up to Node.js 20 would continue to use ```index.js```, to...

Thank you @trparchman. Can you think of any situation where a customer creating an inline function could not use .mjs and would require CommonJS? Adding a parameter has downsides--it adds...