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/

[luizcorreia]

Maybe that way, the Node v18 will be done before past one year.

[mikepage]

Best thing you could do to enjoy Node v18 like-features is move to Netlify. They released Edge functions with Deno deploy: https://www.netlify.com/blog/announcing-serverless-compute-with-edge-functions

Do tell Vercel, they may reconsider using AWS lambda images :)

[chenrui333]

I honestly don't mind receiving flood of email notifications, since we really need to get more ppl to pressure AWS to stay on top of this NodeJS runtime update game.

[davecarlson]

Maybe that way, the Node v18 will be done before past one year.

Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"

[vith]

Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"

Isn't that what the 6 months between v18 release on 2022-04-19 and v18 becoming LTS on 2022-10-25 is for?

Amazon can start making v18 images available now if they want to have 6 months of testing before offering v18 as LTS.

[davecarlson]

Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"

Isn't that what the 6 months between v18 release on 2022-04-19 and v18 becoming LTS on 2022-10-25 is for?

Amazon can start making v18 images available now if they want to have 6 months of testing before offering v18 as LTS.

Yes, that's exactly my point - AWS just also use that same bake time to prepare, then launch the node version as soon as it becomes active LTS

[dl748]

Should be noted as well, that they will be transitioning to Javascript SDK V3 as well for the default SDK.

[adcreare]

Like many others I agree with the sentiments, AWS needs to get better on this.
I suggest everyone bug their account managers, technical account managers and log support tickets if you haven’t already.

I went back and dug out the release history of lambda back to node 8. It is not a pretty sight.

The current delay is second only to the delay with the node 10 release, that took until May 13. After Node 10 things got better - Node 12 dropped very promptly, 14 it started to drift back out and with 16 we’re back to at least May.

Interesting to note the other two major cloud providers, ie Google and Azure, did manage to get 16 out in a timely manner.

Node 16: 
	Node LTS: 2021-10-26
	AWS Lambda Release:  ???
	Google Cloud Functions release: 2021-11-17
	Azure  Functions release: 2021-11-22
Node 14: 
	Node LTS: 2020-10-20
	AWS Lambda Release: 2021-02-03
Node 12: 
	Node LTS: 2019-10-22 
	AWS Lambda Release: 2019-11-18
Node 10:
	Node LTS: 2018-10-30
	AWS Lambda Release: 2019-05-13
Node 8:
	Node LTS: 2017-10-31
	AWS Lambda Release: 2018-04-02

[paul-uz]

@adcreare I mean, it's not like Amazon is a multi-billion dollar company.... oh wait

[jtuliani]

Thanks all for the keen interest in seeing Node releases land promptly in Lambda.

Regarding Node releases in general, we're tracking the Active LTS release dates in October, not the 'Current' release dates in April. This is because, as stated at https://nodejs.org/en/about/releases/, "Production applications should only use Active LTS or Maintenance LTS releases".

As @adcreare pointed out above, there have been delays between Active LTS and our corresponding GA releases, not least for Node 16 (see #14 for latest status). While I can't give an ETA for Node 18 yet, we do hear your feedback and this is something we're actively working to improve.

[faradaytrs]

@jtuliani Well you could add it as beta status or something, actually node 12 is also not usable in production because it's not supported anymore, but you still have this runtime supported. I think it's nothing bad about thinking of new releases in advance. "Current" version is stable enough for some simple applications. It's a good idea to release it right when it hits lts status.
Having this runtime for lambda doesn't equal using it in production. We might use it in testing instances.

[GrahamCampbell]

Regarding Node releases in general, we're tracking the Active LTS release dates in October, not the 'Current' release dates in April. This is because, as stated at https://nodejs.org/en/about/releases/, "Production applications should only use Active LTS or Maintenance LTS releases".

Then why is your node 16 image that is just released based on node 16.4, which by your version definition, should not be used in production, because it was released multiple months before the first 16.x LTS version!!!

[dl748]

@jtuliani Well you could add it as beta status or something

This is "close" to what I'd like. i'm thinking more like nodejs18.x-experimental that can only to assigned through the API/CLI and not through the console (currently how 16 is working now). Where, if they are are worried about support, have a flag that needs to be sent via API, "agree_experimental": true when sending a runtime of "*-experimental", where the usage agreement is "use at your own risk".... then when GA is ready or close, they make a nodejs18.x

This would allow us to deploy an experimental version and allow us to fix bugs ahead of the GA releases.

If someone wants to use this for production purposes, that's their issue then as they agreed to the terms.

[barneyparker]

-experimental feels problematic in that at some point when the runtime goes GA, AWS need to modify a whole bunch of lambda configs to remove the suffix. Published version configurations would then be modified, which should never happen.

That said, agree_experimental: true is a reasonable thing for non-GA runtimes since that would be required for the API to not fail the call, but would leave things in the correct state at GA - the agreement doesn't need to be stored, its implied by the fact that the API accepted the request.

[dl748]

There shouldn't be a need to remove any configs, however it would be more aggressive on the removal of the runtimes. I would just say, create a new GA runtime without the suffix, and either remove the *-experimental runtime immediately or after a month. They already have policy and protocols for deprecation. The only other thing is, I'd probably disallow the runtime's for @edge.

The nice thing about it is. Once a GA is announced then they deprecate and immediately release the "next" LTS version. So, if they have node18.x-experimental... after the GA, they release node18.x runtime, where both runtimes exist, then they release node20.x-experimental and remove node18.x-experimental. Experimentals are just treated as another runtime.

[barneyparker]

how do customers deal with the fact that they have an -experimental runtime in a published function, but that runtime has been removed?

its easy to say "make the customer do it" but its an impractical answer that leads to unhappy customers. it would be better to use a fixed name that wont change at GA, but force customers to accept its experimental nature pre GA

To some degree i can see your point that they already have a process for deprecating runtimes, but in this instance it would seem more appropriate to not deprecate, but instead automatically onboard in to the non-experimental version at GA since pre GA the runtime may introduce breaking changes but if you're using the runtime pre GA, you presumably want to keep using it post GA.

This would also address @GrahamCampbell's comment on node 16.4 being available pre LTS. This should have required the experimental: true flag to deploy, but would have naturally transitioned at GA without any actions on the part of the customer

[GrahamCampbell]

but would have naturally transitioned at GA without any actions on the part of the customer

However that's not true, because many major bugs and security issues (such as CVE-2021-22930 and CVE-2021-22931) were fixed since the 16.4 release. 16.4.x is not suitable for production use IMO.

[jtuliani]

@GrahamCampbell Please can you clarify how you checked the Node 16 version and which region you used? When I tried a simple function to console.log(process.version); just now in eu-west-1, I see the Node version reported as v16.14.0. Thanks!

[dl748]

@barneyparker The same way they handle deprecated versions of runtimes now. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html#runtime-support-policy
According to documentation

Phase 1 - Lambda no longer applies security patches or other updates to the runtime. You can no longer create functions that use the runtime, but you can continue to update existing functions.

Phase 2 - you can no longer create or update functions that use the runtime. 

Lambda does not block invocations of functions that use deprecated runtime versions. Function invocations continue indefinitely after the runtime version reaches end of support.

So I would expect, as a completely separate runtime, it would follow these steps but at a "faster" pace, and there would only be one "experimental" per GA release

Edit the main problem is that the experimental runtime may have a "bug" thats not present in the GA version.

[jtuliani]

Thanks all for the thoughts on 'preview' runtimes--please keep the ideas flowing. This is also something we're considering (no concrete plans yet). As well as the details of how preview runtimes would work, we're also keen to understand the 'why'...what would you all see as the main benefit(s)? Would you be willing to try runtimes during the preview phase and share feedback?

[dl748]

@jtuliani The Main reason is for developers to deploy a "test" version of their application. This would allow us to iron out any issues with a new version before (90-99%) a GA is deployed. As it is now, when a GA is released, it can be up to a month sometimes for testing and QA teams to work with before we can utilize this in a production environment. Then all that is left is any issues between a "preview" version and the GA runtimes, which should be low.

[willfarrell]

As the core maintainer of Middy, being able to know what will be included in the runtime when it hits GA will allow myself and other OSS projects to better server the AWS Lambda community. Currently, we need to be over conservative or reactionary with major releases which I feel isn't serving the community as well as it could be. Also, having more lead time mean better planning and less rushing to test and publish a new version once GA is released. Frameworks need to be updated and released before, as @dl748 mentioned, other downstream projects/developers can use them.

I like this idea of having the LTS runtime released via to the API/SDK with a simple changelog in GitHub to know if there are any other changes besides the runtime itself. Then having a switch to GA it once the version transitions to LTS, enabling the console and updating the public docs. I don't think the runtime needs a -experimental suffix, just remove the API flag when no longer needed.

Having access to the latest runtime sooner has additional advantages:

• faster, which lowers costs and can be a competitive edge
• fewer polyfills needed (ie fetch, web stream, etc)
• removal of experimental flags (ie json import)
• simpler and safer build process, js may no longer need to be transpiled

Happy to discuss feedback on preview nodejs runtimes and feature requests I've been collecting over the years. The Middy team is already building a relationship with the AWS Lambda Powertools Typescript team to see how we can better work together to serve the community, would love to do the same with the Lambda nodejs runtime team if there is interest.

cc @lmammino @saragerion @dreamorosi @ijemmy @flochaz

[mbklein]

@jtuliani Could there maybe be a way to differentiate pre-released runtimes from released ones? Something like the CAPABILITY flags you have to include in some CloudFormation calls to confirm that you know you're doing what you think you're doing? For example, if I tried to execute CreateFunction with a runtime of nodejs18.x but without some kind of IncludePrereleaseRuntimes parameter, I'd get an InvalidParameterValueException (or something). Including that flag lets me select unsupported runtimes, with the full knowledge that what I'm doing isn't (yet) supported. I think it'd provide a good balance of trusting developers/users with the flexibility to do what they want while still making sure you're not fielding support requests for things in pre-release state.

That said, I understand that changing the public API is way harder than some of the other solutions presented. One way around that might be to change the actual name of the runtime to, say, nodejs18.x-pre until it's supported. Anything that makes selecting it a deliberate act that forces acknowledgment of its prerelease status.

[paulgalow]

I like the idea of implementing Node 18 current and LTS with the same runtime name of nodejs18.x. I see a chance this might make it easier for adjacent software projects to keep their runtime support up to date and implement support by the time Node 18 LTS is released.

For example: Frameworks like Serverless Framework, plugins (like serverless-esbuild) or IDE extensions like Serverless IDE. All of them have/had to add support for the latest runtime and all of them have been blocked/waiting until May 9 to get started, making an already late runtime release take even longer because of the time required for dependencies to follow suit.

If AWS released nodejs18.x before Node 18 LTS, all of those projects could start working on support for it months earlier. And as mentioned before, we all could run and test Node 18 current much earlier to iron out issues. So by the time LTS hits, we could have a much more mature state of support throughout the ecosystem.

[pbadenski]

FYI As AWS is painfully slow at releasing new versions of node images we build our own lambda layers. We've been running our services on the latest node using layers for number of years now. At the moment we are not even able to do that as Node 18 requires glibc >= 2.28 currently unsupported by Amazon Linux (AL1 and AL2). What I think it means - is that we will not have Node 18 on AWS Lambda until it's operating on Amazon Linux 2022 (also see: https://repost.aws/questions/QUrXOioL46RcCnFGyELJWKLw/glibc-2-27-on-amazon-linux-2).

[willfarrell]

NodeJS just moved up the EoL for v16 to 2023-09-11! The race is now on for all vendors to release v18 ASAP to ensure customers have sufficient time to upgrade. Hopefully this will force a new release schedule.

https://nodejs.org/en/blog/announcements/nodejs16-eol

[lmammino]

I totally agree with @willfarrell that this is becoming much more of a priority right now. Hopefully AWS can prioritise this work

[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?

[paul-uz]

How is that single JS then referenced in my actual function? Does esbuild handle that as well?

[simlu]

I guess this thread has now completely derailed, so I'm going to unsubscribe. However, relevant to the recent discussion, please take a look at "@vercel/ncc". We've been using it for hundreds of production lambda functions (and billions of executions) to bring down cold start / package size. It might take a bit of tinkering to get to work (depending on your dependencies - really helps if you have tests you can run against the compiled code), but the impact on cold start times is fantastic.

[paul-uz]

@ffxsam I gave esbuild a quick test, and it seems to be working, mostly. I don't think tree-shaking is working by default though, as an included package I wrote is having all its functions bundled, not just the one being used in my main file.

[koshic]

@paul-uz plz read https://esbuild.github.io/api/#tree-shaking and stop posting irrelevant comments here )