I have a basic node web application using express that has a dependency on the node-sass library.
This is being built on a Win64 server, so during the npm install part of the build it is downloading the x64 version of the binding binary due to the current environment.
When its deployed to Azure App Service it throws a runtime error due to incompatability with the node-sass binding binary, as node runs 32bit in Azure App Service...
Error: Missing binding D:\home\site\wwwroot\node_modules\node-sass\vendor\win32-ia32-48\binding.node Node Sass could not find a binding for your current environment: Windows 32-bit with Node.js 6.x
Found bindings for the following environments: - Windows 64-bit with Node.js 6.x
When i explicitly check in the 32bit binding and re-deploy i sometimes get a 502 gateway error...
502 - Web server received an invalid response while acting as a gateway or proxy server. There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.
and other times i simply get a 500, but it no longer writes the error to the log.
The app depends on node-sass-middleware package version 0.11 explicitly, which depends on node-sass 4.3.0.
Without any error logs i am at a dead end. Have you come across this issue before, and if so, how did you resolve it?
We eventually resolved this by swapping out node-sass-middleware for gulp-sass, and also adding an npm rebuild step for node-sass. The key difference here is that the css is now rendered during the build process via gulp. Running npm rebuild node-sass first would invoke the binding download to the build server (if necessary), and then a separate task would invoke a gulp task to render the css.
The remainder of our problem was due to the fact that the web.config specified app.js as the entry point, but express4 uses the bin/www file, and simply references app.js. The problem with bin/www being the entry point is that iisnode now uses bin as the working directory, which caused issues with root relative references.
Rather than waste any more time trying to figure out if we could configure a different working directory, we simply moved bin/www to ./server.js and changed the web.config to point to server.js
The express app now runs as expected on azure websites.