fix: Ensure custom resource runtime is at least Node 18

[jackylamhk]

Reopens #60

While the default custom resources runtime version has been bumped to Node 22, the plugin still does not make sure that the provider runtime version is at least Node 18.

AWS only includes AWS SDK v2 for Node <= 16 and v3 for Node >= 18 on Lambda. Without this check, the custom resources invocations will fail if the provider runtime is set to Node 16 or lower.

[GrahamCampbell]

I'm not sure we should actually fix this, and instead we could drop support for node 16 early.

[tonyliu-raken]

According to https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html, nodejs18.x is no longer supported.

[jackylamhk]

AWS doesn't advertise this, for obvious reasons, but you can still create and update functions with EOL runtimes via the API (and therefore CloudFormation and Serverless). This check simply ensures backward compatibility without providing any extra support.
The current workaround is to set the runtime for each function individually, so provider.runtime remains unset.

[mnapoli]

@jackylamhk do you think this is the cause behind #128 and brefphp/bref#2034 ?

I'm wondering if these failures with custom resources might be related

[jackylamhk]

@jackylamhk do you think this is the cause behind #128 and brefphp/bref#2034 ?

I'm wondering if these failures with custom resources might be related

It's possible, but I'd want to see the CloudFormation events and CloudWatch logs (if any; as you have asked) to be sure. And I'd also check what provider.runtime is set to.

[mnapoli]

I'm all for dropping support for Node 16, but see #130 and other issues linked, I believe this might be affecting several people. I'll merge this in the meantime to see if it helps.