Node v18 Released

[chenrui333]

Even though we are still waiting for node v16 base image, this is the issue tracker for node v18 base image

https://nodejs.org/en/blog/announcements/v18-release-announce/

[thdxr]

what linux kernel version is this using?

[GrahamCampbell]

the same as the node 16 ones i presume. the one al2 uses.

[jtuliani]

The kernel is not part of the runtime. All Lambda runtimes inherit their kernel from the MicroVM in which they run (see diagram on page 11 of https://docs.aws.amazon.com/pdfs/whitepapers/latest/security-overview-aws-lambda/security-overview-aws-lambda.pdf). Currently, this is kernel v4.14.

[michael-k]

Release 1.65.0 of AWS SAM CLI comes with support for Node.js 18.x.

[antspk]

2.51.0 AWS CDK comes with Node.js 18 runtime support as well 🎉 . Keen to see when it's going to be available on codebuild as well.

[michael-k]

For CodeBuild see aws/aws-codebuild-docker-images#580

[RaphaelManke]

I've build a cdk example that uses the node 18 runtime. https://github.com/RaphaelManke/cdk-lambda-node-18

[o-alexandrov]

Please let us know when to expect:

• Node.js 18 for Lambda@Edge

[Sparticuz]

https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html?icmpid=docs_lambda_rss

Looks like it's hit lambda proper.

[jtuliani]

Node 18 support in Lambda has shipped!

https://aws.amazon.com/about-aws/whats-new/2022/11/aws-lambda-support-node-js-18/

https://aws.amazon.com/blogs/compute/node-js-18-x-runtime-now-available-in-aws-lambda/

Thank you all for the input and feedback on this thread.

[laymonage]

Node.js 16 release: 2021-04-20 Node.js 16 active LTS start: 2021-10-26 AWS Lambda Node 16 support: 2022-05-12 LTS-to-support: 198 days

Node.js 18 release: 2022-04-19 Node.js 18 active LTS start: 2022-10-25 AWS Lambda Node 18 support: 2022-11-18 LTS-to-support: 24 days

That's a big improvement!

I remember a lot of people (myself included) complaining about how Node.js 16 support came very late. Now that Node.js 18 support came in a reasonably timely manner, I feel we need to give credit where it's due 🙂

Congratulations and thanks @jtuliani & team! 🎉

Now, see if AWS can beat the record when Node.js 20 comes out 😜

[jlarmstrongiv]

Great news!

@jtuliani will you and the team update https://github.com/aws/aws-lambda-nodejs-runtime-interface-client to match the Node.js 18 release?

Features described in the blog post, like ES Module support https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/issues/44, do not work. This support is very important for custom docker containers.

[paul-uz]

Excellent news, and the cherry on the top is that the ESM Module & Lamda Layer issue has also been fixed 🙏

[jtuliani]

@jlarmstrongiv You're right that the public runtime interface client is not currently in sync with our Node 18 version. It is something we want to address. Can I suggest you file a separate issue for this, for tracking purposes and for others to weigh in with their feedback?

[jtuliani]

Thank you @paul-uz and @laymonage for your kind words. We're still not where we'd like to be across other languages, but we are continuing our work to improve.

[chenrui333]

@jtuliani Congratulations on the nodejs v18 runtime release!

Worth calling out that the node.js 18 runtime seems slower than the node.js 16 runtime, any reason why that happened? Thanks! https://twitter.com/sussmansa/status/1593804631192346624?s=46&t=faTnOE-p9Hnj0qf7-KYT2g

[daniele-sarnari-blinkoo]

Do you know how to create lambda using node.js 16? I can't create a lambda edge because nodejs 16 is no more available

[paul-uz]

Do you know how to create lambda using node.js 16? I can't create a lambda edge because nodejs 16 is no more available

Why can't you use 18?

[daniele-sarnari-blinkoo]

Do you know how to create lambda using node.js 16? I can't create a lambda edge because nodejs 16 is no more available

Why can't you use 18?

[daniele-sarnari-blinkoo]

nvm, fixed with aws lambda update-function-configuration --function-name <funcname> --runtime nodejs16.x

[willfarrell]

Big congrats to the lambda runtime team on this release! Exciting to see the ESM + Lambda layer now supported.

Middy v4 is now released for nodejs18.x runtime and now uses AWS SDK v3.

[JacksonGariety]

I'm curious about the cold start problem pointed out by @chenrui333. Can the AWS team shed some light on this?

[jtuliani]

@chenrui333 @JacksonGariety We're aware of the reports of longer cold starts on Node 18 and we're investigating the issue. We'll report back once those investigations are complete.

[paul-uz]

@jtuliani I found this issue, https://github.com/aws/aws-sdk-js-v3/issues/4225, when writing some new functions.

Is this intended behaviour?

I (probably wrongly) assumed that the embedded SDK would work in combination with a local node_modules folder in the function, but it seems like it doesn't.

[jtuliani]

@paul-uz Thanks for flagging, I'll find out and revert.

[dvargas92495]

@jtuliani Any ETA on when node18 will be supported in Lambda@Edge?

[aukevanleeuwen]

@chenrui333 @JacksonGariety We're aware of the reports of longer cold starts on Node 18 and we're investigating the issue. We'll report back once those investigations are complete.

@jtuliani we are also experiencing this. Is there a GitHub issue or somewhere else where we can track the progress on this investigation? This is blocking us from moving away from 16 at the moment.

[o-alexandrov]

cc @jtuliani Regarding cold starts, there's a great article by Yan Cui from a couple of years ago that is still applicable. TLDR img from the article is attached below.

• even though the numbers mentioned in the article already prove its points, you could further optimize aws-sdk by substituting process.env.* vars aws-sdk depends on (ex. credentials resolution) during minification

For best performance/cold starts, bundle aws-sdk and don't depend on AWS-provided SDK

• you stop to control the version and thus, AWS could either introduce a regression you wouldn't notice until you get an error (instead of testing before deployment) or you would depend on a feature that is not released yet and works locally, but not remotely.

Unfortunately, AWS didn't (or couldn't) listen to the community in the Node.js v16 thread, so we don't have an SDK-free node.js (hopefully soon Bun also) runtime.

[asilvas]

Bun support would be a perfect fit for lambda's due to fast cold start, but it's quite a few months from v1 and I doubt AWS will even consider it prior to that.

[paul-uz]

Bun support would be a perfect fit for lambda's due to fast cold start, but it's quite a few months from v1 and I doubt AWS will even consider it prior to that.

I doubt we'll ever see the likes of Bun or even Deno. Shame.

[o-alexandrov]

@jtuliani thank you for the new feature, AWS Lambda runtime management controls.

• does the article mean we are closer to a possibility of selecting (toggling) a runtime node.js/deno/bun at some point in the future?
  • since from now on there'd be all versions of node.js available (e.g. 15 versions for node.js 18 as of now), maybe it'd make sense to delight customers by offering a minimal, reasonable for AWS, number of versions for deno & bun

[jtuliani]

@o-alexandrov Supporting new runtimes such as Deno or Bun would be a separate feature, it's not enabled by runtime management controls. I'm interested to learn more about your use case for Deno and/or Bun. How would they help you?

[o-alexandrov]

@jtuliani thank you for considering this request. imho:

• bun would excite customers due to the performance reasons
  • community (ex. sharp in this issue) already considers adding support for bun, so I believe in such performance-critical aspects, like image processing bun would be a good fit for AWS Lambda
  • especially for S3 Object Lambda, Lambda@Edge, and hopefully for CloudFront's Edge functions when limits would be higher
• deno is less attractive to me personally than bun, I see deno being different to node.js only in style rather than anything measurable (including security-related differences)

[santiperone]

@jtuliani Has there been any updates on the cold start issue with node.js v18?

[paul-uz]

@jtuliani Has there been any updates on the cold start issue with node.js v18?

What's the cold start issue?

[santiperone]

@jtuliani Has there been any updates on the cold start issue with node.js v18?

What's the cold start issue?

Node 18 has longer cold start in comparison to node 16

@chenrui333 @JacksonGariety We're aware of the reports of longer cold starts on Node 18 and we're investigating the issue. We'll report back once those investigations are complete.

[jtuliani]

@santiperone Thanks for following up. We have identified the primary cause of the longer cold starts in the Node 18 runtime as thread blocking in a dependency used during initialization. We are evaluating options to resolve this in a future Node 18 runtime update.

[paul-uz]

@santiperone Thanks for following up. We have identified the primary cause of the longer cold starts in the Node 18 runtime as thread blocking in a dependency used during initialization. We are evaluating options to resolve this in a future Node 18 runtime update.

What's the rough ETA on that update? I hope its sometime this year...

[thdxr]

that's excellent news, is it something in the aws lambda runtime interface client?

[willfarrell]

This was in a newsletter from Node Weekly I received today:

Lambda Cold Starts is a neat page giving a live demonstration of how quickly different AWS Lambda serverless runtimes take to start. Given Node's mature status on Lambda, it does surprisingly poorly?

Seems others have noticed too.

[paul-uz]

This was in a newsletter from Node Weekly I received today:

Lambda Cold Starts is a neat page giving a live demonstration of how quickly different AWS Lambda serverless runtimes take to start. Given Node's mature status on Lambda, it does surprisingly poorly?

Seems others have noticed too.

How embarrassing.

[o-alexandrov]

This is slightly related to performance questions:

• Bun released custom runtime AWS Lambda layer

Maybe, AWS would kindly consider to provide us with managed by AWS Bun runtime.

[bicatu]

any news regarding this issue? is there a ticket we can subscribe to be notified of this progress?

[o-alexandrov]

@chenrui333 @JacksonGariety We're aware of the reports of longer cold starts on Node 18 and we're investigating the issue. We'll report back once those investigations are complete.

@bicatu this ticket is closed, Node.js 18 is available for all Lambda, including Lambda@Edge (support added in January 2023 if I'm not mistaken), some of us just shamelessly pinged AWS here 😅 having an opportunity to be heard

I just created a separate ticket #83 regarding cold starts, so it's in Open state and has less probability of being postponed.

[ffxsam]

There's still the issue of performance when using the built-in runtime's SDK: https://dev.to/aws-builders/benchmarking-the-aws-sdk-2pd4

[paul-uz]

@ffxsam funnily enough, I read that same article last night.

Anyone here got a good example/tutorial on using esbuild with Typescript and tree shaking? I can't seem to find anything decent online :/

[ffxsam]

@paul-uz What, specifically, are you looking for?

[paul-uz]

@ffxsam how to configure esbuild to compile TS and do tree-shaking (and minification).

[ffxsam]

@paul-uz Tree-shaking is automatic in esbuild, as far as I know. As a test, just create an index.ts file and add a package (like date-fns). Import a function from date-fns, use it in some way, then do:

$ esbuild index.ts --bundle --format=cjs --minify --outfile=min.js

Or --format=esm depending on where you're deploying.

[paul-uz]

@ffxsam oh sweet. TBH I've simply not yet tried it, as we currently just use TS to compile the JS files, and bundle all the production NPM dependencies in a ZIP.

So, I can use esbuild to compile the TS into JS, at the same time, tree-shaking and minifying everything? So in theory I would end up with a JS file and a trimmed down node_modules folder? Or does esbuild create something else that gets imported?