I have a Netlify site (mynt-condition-app.netlify.app) with a /graphql serverless function that uses Prisma.
My .nvmrc previously set the Node version for the site to lts/*. As a result, when Node updated LTS to version 20, my Prisma client broke (as described in New Builds are breaking in runtime with Prisma errors), and the graphql function stopped working.
On 2023-12-30T08:00:00Z, I updated my .nvmrc to pin the Node version to v18 as a temporary fix for the Prisma issue. Since then, for branch deploys and deploy previews, the graphql function has used Node 18 as expected and therefore worked:
However, on the production deploy, the graphql function is still using Node 20.
I suspect that the issue may have something to do with the fact that the function was created on 2023-12-30T08:00:00Z, presumably before I updated the .nvmrc.
Since then, I have made numerous updates to the main branch, including adding a comment to the graphql function file and event deleting and then restoring it. Still, the “Functions” page says that the function was created on December 30, and the function is using Node 20.
How can I force this function to use Node 18 going forward?
Node version for production deploy:
Why do you want to use Node 18 though? I believe the issue with Prima client not working on Node 20 is fixed, so what exactly are you trying to solve?
Good question. Eventually, we do we want to upgrade Prisma to at least 5.7 (the version that works with Node 20). However, we’re using RedwoodJS, and in order to upgrade Prisma, we need to upgrade Redwood, which will require several code changes (as described here). Additionally, RedwoodJS does not officially support Node 20 yet.
Regardless of these specific circumstances, though, shouldn’t it be possible for a Netlify user to set the version of Node that they want to use in their serverless functions?
Well this is interesting. I’m seeing the functions have been set to use Node.js 18 in the backend, but the logs say otherwise. I have checked all the settings that could apply from our end to set the version, and while I’d have thought everything is working as intended, the logs don’t agree. I’ll ask the devs to check this.
Oh wait, I did find a setting where this is mis-configured. Though, I don’t believe it’s possible to edit it, so I’ll still need some dev help to understand where it’s coming from.
Could you try setting:
AWS_LAMBDA_JS_RUNTIME
environment variable to nodejs18.x?
Looks like that did the trick. Thanks so much for your help, @hrishikesh!
