node.js - Azure NodeJS version

Question

Ok I give up. Why does Azure have some default version of node (0.10.x for gawds sake) and then relies on using hard-coded paths for the specific version required? That was not my question (it was rhetorical).

The problem with this arrangement is that it seems that "internal" (to the app) calls are made to node and of course the one in $PATH is used.

We have an nodejs, express, angular app.

My first problem (though not the causes for this post) was that I have nested package.json files in /, angular/ and server/ directories. The root one calls install on the sub-directories. This does not work in Azure.

I had to move the calls to gulp and ng out to the Azure deploy.sh by making hard-coded references to the installed node modules. The deploy.sh contains:

#!/bin/bash

...
NODE_EXE=`cat "$DEPLOYMENT_TEMP/__nodeVersion.tmp"`
NPM_CMD=""$NODE_EXE" "$NPM_JS_PATH""
GRUNT_CMD=""$NODE_EXE" ./node_modules/gulp/bin/gulp.js"
NG_CMD=""$NODE_EXE" ./node_modules/@angular/cli/bin/ng"

...

cd server
eval $NPM_CMD install --production
eval $GRUNT_CMD build

cd ../angular
eval $NPM_CMD install --production
eval $NG_CMD build --prod

cd ..

As part of the NG production build is a mimification step. It appears to have an 'internal node call' and is failing:

remote: Selected node.js version 10.14.1. Use package.json file to choose a different version.
remote: Selected npm version 6.4.1
...
...
...
remote: Date: 2019-01-04T04:20:42.367Z
remote: ERROR in ./src/styles.scss
remote: Hash: 8062ccafe553f9f5894b
remote: Time: 33752ms
remote: chunk {0} runtime.ec2944dd8b20ec099bf3.js (runtime) 1.41 kB [entry] [rendered]
remote: chunk {1} main.9868d9b237c3a48c54da.js (main) 128 bytes [initial] [rendered]
remote: chunk {2} polyfills.85f47f0bf59079cbc23a.js (polyfills) 130 bytes [initial] [rendered]
remote: chunk {3}  (styles) [initial] [rendered]
remote: An error has occurred during web site deployment.
remote: Module build failed (from D:/home/site/wwwroot/angular/node_modules/mini-css-extract-plugin/dist/loader.js):
remote: ng build in angular failed
remote: ModuleBuildError: Module build failed (from D:/home/site/wwwroot/angular/node_modules/sass-loader/lib/loader.js):
remote: Error: Missing binding D:homesitewwwrootangular
ode_modules
ode-sassvendorwin32-ia32-64inding.node
remote: Node Sass could not find a binding for your current environment: Windows 32-bit with Node.js 10.x
remote:
remote: Found bindings for the following environments:
remote:   - Windows 32-bit with Node 0.10.x

The ./src/styles.scss contains:

@import '~@dhsui/kit/styles/dhs-kit-all';
@import "~bootstrap/dist/css/bootstrap.css";

I tried making a change to prepend the desired version of node directory to the PATH (and changed to just calling node rather than the full path that Azure seems to require you to do):

NODE_DIR=$(dirname "$(echo $NODE_EXE | tr '\' '/')" | tr '/' '\')
export PATH=$NODE_DIR:$PATH

But it failed at the same place. So it seems my problem is not that "internal" (to the app) calls are made to node and of course the one in $PATH is used.! (This change actually didn't work so I reverted).

Does anyone know why the binding has been setup for Node 0.10.x and what can be done to prevent this problem?

Answer 1

There is a wiki page Node versioning of Project Kudu for Azure WebApps which can answer your question about Node version. Before Oct 31, 2017 when the wiki page be edited， the default node version is v0.6.20, now it is 0.10.40. It seems to be up to the deployment template of Azure WebApps.

After your webapp was created, you can configure the value of Azure Website environment variable WEBSITE_NODE_DEFAULT_VERSION to change the default Node version in the tab Application settings of Azure portal, as the figure below, like the subsection Change the Node version of the wiki page Configurable settings said.

About the all available Node versions in Azure WebApps, you can command ls under the path D:Program Files (x86) odejs of Kudu console to list them as the figure below.

After you set the WEBSITE_NODE_DEFAULT_VERSION, your website will autorestart and the Node version has been upgraded.

Then you can make your script works directly on the current Node version, without considering for these environment variables like PATH or others about Node.