WEBSITE_NODE_DEFAULT_VERSION not working in Linux

[awoSYS]

My WEBSITE_NODE_DEFAULT_VERSION is ~10, but if I check the actual Node version (context.log(process.version);) it prints v8.17.0. Is there another setting that affects the Node.js version?

I was pointed at that, when my app crashed with error message

Worker was unable to load function status: 'SyntaxError: Unexpected reserved word'
Stack: /home/site/wwwroot/common/xxx.js:195
  for await (const c of blobServiceClient.listContainers()) {
      ^^^^^

Which seems to be Node.js version related (for await supported after v10.0.0).

Investigative information

Please provide the following:

• Timestamp: 2020-01-30 16:52:14.006
• Function App name: dummyfunapp
• Function name(s) (as appropriate): HttpTrigger
• Invocation ID: e8f7c2eb-4c0d-4a5e-81e6-cdda996f5768
• Region: West Europe

Repro steps

1. Create Function App Runtime Version 2
2. Create Function that does context.log(process.version);
3. Run Function from Portal

Expected behavior

Output: v10.xx.xx

Actual behavior

Output: v8.17.0

Related information

• I'm developing locally (VS Code) and publish function app via VS Code Tool
• Function App OS: Linux
• Runtime Version: 2.0.12969.0

[mhoeger]

Known issue for Linux :( Very sorry :( We're waiting on a better UX to light up soon that brings version selection to one spot.

The easiest way to get 10.x is to run on functions v3 (FUNCTIONS_EXTENSION_VERSION=~3). Can you try that?

[mhoeger]

And most of the changes from V2 => V3 are bug fixes that were technically breaking: https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions#javascript

[awoSYS]

@mhoeger thanks for your feedback!
Meanwhile I switched to Windows, Functions v2 which works. (Local testing with "version": "3.0" in host.json failed for me).
Btw, whats the difference between running Functions on Windows or Linux in Azure? I only guessed that Linux would be more appropriate for me since I'm developing on an Ubuntu machine.

[mhoeger]

@awoSYS - Version here is overloaded, it means host.json schema version 2 (http://json.schemastore.org/host), which applies to functions runtime V2 & V3

A lot of the differences between Linux and Windows are a point in time thing (ex: not having a good way of changing Node.js versions). The Linux offering is much newer, and so there are some experiences that still need to be ironed-out. So at this moment in time, our Windows offering is going to be a smoother experience with fewer snags. That being said, there are talks on our end of switching Linux to be default for Node.js functions. We're working towards parity between Windows and Linux experiences because it shouldn't matter!

[rwebb-sgefdf]

This could be related to an issue I'm seeing:
Using function runtime 3.0.14120.0, and WEBSITE_NODE_DEFAULT_VERSION ~12 on Linux reports Node version 10.21 when following the same steps as above (logging process.version in an HTTP trigger)- is this related to the issue above as well?

I came across this after being surprised Object.fromEntries wouldn't work. My "fix" is to use lodash _.fromPairs.

Would my issue be solved by resolving this issue?

[mhoeger]

@divyagandhii - I'm assuming that we have the node 12 image for functions deployed? do we have any docs on how to change linuxfxversion?

[divyagandhisethi]

@rwebb-sgefdf @mhoeger is right..WEBSITE_NODE_DEFAULT_VERSION is not honored on Linux function apps. You need to set the 'linuxfxversion' property of your app to node|12 to make it a node 12 app. You can do this by either using the azure resource explorer - https://microsoft.github.io/AzureTipsAndTricks/blog/tip25.html or use any of the arm templates - https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create-a-function-app-2 to update your app's linuxfxversion.

[mhoeger]

cc: @anthonychu as FYI

[rwebb-sgefdf]

Thanks everyone - this has worked great for us.

In case anyone else stumbles across this, we were using terraform, and managed to update this setting like so:

  site_config {
    linux_fx_version = "node|12"
    ...

[mathiasmaerker]

@divyagandhii I tried to follow the resource explorer route, but the property is not updated at all, I use
az resource update --id /subscriptions/xxx/resourceGroups/puppeteer-test/providers/Microsoft.Web/sites/puppeteer-app2?api-version=2015-08-01 --set properties.siteConfig.linuxFxVersion='"node|12"' in power shell but the value is not set at all. is there any way in e.g. the portal on how to change this?
Thanks for youe help

Regards Mathias

[divyagandhisethi]

@mathiasmaerker I see that linuxfxversion is set to node|12 for your app. You should be on node12 now.

[anthonychu]

@mhoeger @divyagandhii Can we do something to block when setting WEBSITE_NODE_DEFAULT_VERSION on Linux? I guess we could have the Node worker warn about this as well. Would love to come up with something here to let customers how to do this correctly.

[mathiasmaerker]

Hi @divyagandhii I just checked with az resource show..but the ouput is still

[divyagandhisethi]

Hi @mathiasmaerker I can repro this issue in az cli as well. Filed a bug here- Azure/azure-cli#15171
As for your app, I validated it is set to node12 in the backend. Your app will land on node12 containers.

[mathiasmaerker]

Hi @divyagandhii first thanks for your support! But unfortunately when I try to start the function app localy I get the following error

I redownloaded local settings etc. to make sure it is up to date but the runtime seems still to be node 10

[divyagandhisethi]

@mhoeger - do we not support running node12 locally? I believe it is LTS?

[mhoeger]

@mathiasmaerker - what version of core tools are you using? It looks like an older version of V2, which blocked using node 12 before it was LTS. See supported node versions per function version here:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node#node-version

[mathiasmaerker]

@mhoeger you where right, core tools had to be updated, sorry for not checking 😞 Thanks everybody for the great support!

[rsousa88]

I can confirm this works:

1. Updated Core Tools to latest version (2.7.2936)
2. Checked linuxFxVersion (it was NODE|10)
   az resource show --id /subscriptions/*****/resourceGroups/***-resource-group/providers/Microsoft.Web/sites/***-function-app
3. Updated linuxFxVersion value to NODE|12
az resource update --id /subscriptions/*****/resourceGroups/***-resource-group/providers/Microsoft.Web/sites/***-function-app --set properties.siteConfig.linuxFxVersion='"NODE|12"'
4. Ran local debugger and it worked like a charm

[katlimruiz]

Wasn't it easier to simply read also WEBSITE_NODE_DEFAULT_VERSION in linux? I guess this would be the sound question.

Or somehow in the engine use both interchangeable so the outer interface remain the same. Common sense would tell you that linux and windows should not differ as much (sometimes it looks like Azure promotes Windows for this matter).

(enough rant), thanks for the examples and help.

[maximivanov]

Maybe it will be useful to someone finding this thread: I've tried to combine the information on how to change Node.js version in Linux/Windows function apps via Portal / Azure CLI / ARM / Terraform / Powershell: https://www.maxivanov.io/change-nodejs-version-in-azure-functions/

Basically I've created 4 function apps (Windows/Linux x Premium/Consumption) to verify the version change process. In a nutshell:

• Find out current Functions runtime version, upgrade if needed
• Find out current Node.js version
• Change Node.js version using your preferred method. For Linux change LinuxFxVersion site config, on Windows update WEBSITE_NODE_DEFAULT_VERSION app setting.

[anthonychu]

How to configure Node.js versions is also in our docs: https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node?tabs=v2#setting-the-node-version

Also added a work item to see if we can detect when this setting is applied to Linux.

@katlimruiz This is currently a limitation in how the different platforms select a worker that has the correct Node.js version for running your app. It's true that the runtimes are the same on all platforms, but this selection logic is separate from the runtime.

[asbjornu]

Is this a problem for regular App Service as well? I've tried setting engine and WEBSITE_NODE_DEFAULT_VERSION to 14, but the app service is still locked to v12.19.0.

[balag0]

yes linux webapps work the same way wrt WEBSITE_NODE_DEFAULT_VERSION

[asbjornu]

@balag0, nope; setting WEBSITE_NODE_DEFAULT_VERSION had absolutely no effect. What I had to do is documented on Stack Overflow:

For me, the solution was neither to set the engine version in package.json, nor to set WEBSITE_NODE_DEFAULT_VERSION, but to use the az command line as described here:

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "NODE|14-lts"