kudu: Node.js deployment succeeds but doesn't work if server.js/app.js doesn't exist at deployment.

Why can’t we choose our own start script or path? People using Typescript always compile code to ./build or ./dist folder. The most ironic thing is both Azure and Typescript are from MS but this two things couldn’t work properly at the same time. So stupid.

I had the same issue. Had to hack it in by adding the following just before the KuduSync step. That way, Kudusync copies it down to the root and then we can replace it with the real one. I needed this because the server.js is built after the KuduSync with tsc

Deploy.sh

# -------------------------------------------
#create a dummy server.js
touch $DEPLOYMENT_SOURCE/server.js
# -------------------------------------------

# 1. KuduSync
if [[ "$IN_PLACE_DEPLOYMENT" -ne "1" ]]; then ...

I think, the problem is that KuduSync is doing too many things. Should be broken into couple of steps so it checks for the Web.config generation after other build steps are done.

Had to use the solution above, but I think this should be handled better.

The npm start (or the analogous for IISNode) command should be executed at the end of the deploy script. That’s what is logically expected.

I’m guessing it’s an ordering issue. The logic that looks for the start file is happening before we run npm, so since gulp is triggered from npm, at the time we look for server.js it’s not there yet. I’d try committing a dummy server.js to see if that fixes things up.

Note that separately from that, you have that error TS2304: Cannot find name 'process' error, but that appears unrelated to this particular issue we’re investigating.

Still a problem 2 years later 👎 this appears to be broken regardless e.g. I compile to a dist folder and point to this from my start script, failed on initial deploy (which based on the above makes sense). However, on a redeploy the dist folder now exists yet the deployment script still complains about not being able to find the start up script 😕

Getting to the point now where just for the sake of getting this going I’m going to have to get rid of the dist folder idea and go for a compiling to the root folder (which is horrible).

If you are hosting an app service. Do the following after implementing all the above and the problem persists.

1. Login to your Azure account.
2. Click in Configuration on the left side menu
3. Select the “Path mappings” tab from the page displayed. 4.Under the “Virtual applications and directories” table click the edit icon and change the “Physical Path” from “site\wwwroot” to site\wwwroot\build
4. Save
5. Run your site.

I’ve worked around this issue by modifying the default deploy.cmd script so that the :Deployment part starts like that:

:Deployment
echo Handling node.js deployment.

:: 0. Create empty lib\app.js to make KuduSync happy
:: see https://github.com/projectkudu/kudu/issues/1753
call :ExecuteCmd mkdir "%DEPLOYMENT_SOURCE%\lib"
call :ExecuteCmd copy NUL "%DEPLOYMENT_SOURCE%\lib\app.js"

Doing that, I don’t have to commit an empy app.js file to git. Ideally though I don’t want to maintain customized deploy.cmd and .deployment files in my repository, so this should be rather solved elsewhere I think.

Thanks @davidebbo - that’s the solution I ended up going with and it did work.

Is there any work that could be done in Kudu to manage this? With more and more people using tools like TypeScript, Babel, Flow, etc - it’s foreseeable that more people may commit source code with the intention of compiling/transpiling on deployment. Perhaps it’s a matter of checking again after npm completes its postinstall? I’m more than happy to jump onto this and create a PR if you can point me in the right direction.

Or, do you have a suggestion for another workflow for this type of deployment?

The other error was a TypeScript warning - I hadn’t set up the project completely or installed the TSDs for Node, etc - I should have taken that out of the error log I shared with you, as it was still processing fine. Unrelated at this stage.