feat: add custom runtime support based on the defined runtime

[lkeijmel]

When creating custom resource functions, try to use the defined runtime of the serverless config. This is useful when your project is already running on a new(er) Node version.

[sander-bol]

This will break deployments for people using non-Node runtimes like Go or .Net, as the custom lambda will still be deployed as NodeJS code which can't be handled by those runtimes.

Perhaps tighten it down a bit to only do this if the runtime identifier starts with node ?

[lkeijmel]

Good catch, didn't think of that. Have changed it with a check for that

[mnapoli]

Thanks! Does this PR mean that there will be an immediate impact for users?

I see that everywhere in tests the default runtime for custom resources changed from node 16 to 18, that will be applied to all user projects?

If yes, is that 100% safe?

[sander-bol]

We (am a colleague of Laurence) have been running this in production for quite some, and it works fine for the custom resources we use.. but we don't use all of them. So... relying on Node's backwards compatibility promises here.

On the other hand, out of the blue not being able to deploy new copies of your stack, or even later down the line even updates to your stack, because AWS follows their deprecation policy and starts blocking deployments to outdated runtimes at some point is going to certainly break things.

The deadlines for NodeJS18.x are:

Deprecation: Sep 1, 2025
Block function creation: Oct 1, 2025
Block function update: Nov 1, 2025

[mnapoli]

Thanks!