I have my application in TypeScript, then use gulp to compile that server-side (using npm's postinstall. This works fine, although I found that the server never starts and Kudu emits that it couldn't find an app.js/server.js in the root directory.
I've worked around this temporarily by committing an empty server.js to the root of my project. This then gets overwritten by the compile process, and my compiled server.js fires up post-install process.
There may be another way I can approach this, but it seems that a great way to handle this would be to read the scripts in the package.json after install is 100% complete and then try to fire up the server. Let me know if I've missed something here though.
Sorry @davidebbo I think I somehow missed your reply. I'll try to get something together in the coming days, if I can replicated again.
Hi @davidebbo - I actually just made some time to do it then.
https://github.com/mrmckeb/node-azure-test
Here's the log from Azure - I can see that it's picking up the gulp file as it's the only JS file around at that time. The package.json points to server.js (which doesn't exist until the gulp file is run).
2015-11-08T04:08:44 Fetching changes.
2015-11-08T04:08:45 Updating submodules.
2015-11-08T04:08:45 Preparing deployment for commit id 'ee1d5f6352'.
2015-11-08T04:08:45 Generating deployment script.
2015-11-08T04:08:45 Using cached version of deployment script (command: 'azure -y --no-dot-deployment -r "D:\home\site\repository" -o "D:\home\site\deployments\tools" --node --sitePath "D:\home\site\repository"').
2015-11-08T04:08:45 Running deployment command...
2015-11-08T04:08:45 Command: "D:\home\site\deployments\tools\deploy.cmd"
2015-11-08T04:08:46 Handling node.js deployment.
2015-11-08T04:08:46 KuduSync.NET from: 'D:\home\site\repository' to: 'D:\home\site\wwwroot'
2015-11-08T04:08:46 Copying file: 'package.json'
2015-11-08T04:08:46 Start script "server.js" from package.json is not found.
2015-11-08T04:08:46 Missing server.js/app.js files, web.config is not generated
2015-11-08T04:08:47 Looking for app.js/server.js under site root.
2015-11-08T04:08:47 Node.js versions available on the platform are: 0.6.17, 0.6.20, 0.8.2, 0.8.19, 0.8.26, 0.8.27, 0.8.28, 0.10.5, 0.10.18, 0.10.21, 0.10.24, 0.10.26, 0.10.28, 0.10.29, 0.10.31, 0.10.32, 0.12.0, 0.12.2, 0.12.3, 0.12.6, 4.0.0, 4.1.0, 4.1.2, 4.2.1, 5.0.0.
2015-11-08T04:08:47 Selected node.js version 4.2.1. Use package.json file to choose a different version.
2015-11-08T04:08:47 Updating iisnode.yml at D:\home\site\wwwroot\iisnode.yml
2015-11-08T04:09:00
2015-11-08T04:09:00 > [email protected] postinstall D:\home\site\wwwroot
2015-11-08T04:09:00 > gulp
2015-11-08T04:09:00
2015-11-08T04:09:10 [04:09:10] Using gulpfile D:\home\site\wwwroot\gulpfile.js
2015-11-08T04:09:10 [04:09:10] Starting 'default'...
2015-11-08T04:09:10 [04:09:10] Finished 'default' after 17 ms
2015-11-08T04:09:12 typescript\config.ts(1,21): error TS2304: Cannot find name 'process'.
2015-11-08T04:09:12 typescript\config.ts(1,41): error TS2304: Cannot find name 'process'.
2015-11-08T04:09:12 [04:09:12] TypeScript: 3 semantic errors
2015-11-08T04:09:12 typescript\server.ts(1,26): error TS2307: Cannot find module 'express'.
2015-11-08T04:09:12 [04:09:12] TypeScript: emit succeeded (with errors)
2015-11-08T04:09:12 npm WARN EPACKAGEJSON [email protected] No description
2015-11-08T04:09:12 Finished successfully.
2015-11-08T04:09:13 Deployment successful.
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.
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.
Hey there. Google took my down to this post, since I have the same problem.
I'd also love it if I didn't have to create a dummy file. Checking for the npm start post-install would likely solve this.
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.
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.
Same issue encountered. Please help make a fix.
Yep. Same here.
is it possible to inject our own selectNodeVersion.js into deploy.cmd?
@phaattran You should be able to do this by using a custom deployment script and swapping out the logic that looks for and calls selectNodeVersion.js with your own.
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).
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.
After having problems getting npm running on azure this is yet another hurdle to what should have been a simple deployment. None of the samples I see have build steps so I feel like azure wants us to use a different workflow - like maybe to build ourselves and check in the built files and node_modules, etc? I know they sell integration tools maybe they expect those tools should do the build?
I feel like I am not doing anything special. I just need a build step because I use typescript but I just want my deployment to be as standard as possible.
Editing deploy.cmd feels hacky and the .deployment file is used by both linux and windows deployments so what I did is to make a start.js in the root that has one line require('./dist/server') then I set this as my start script in package.json. I really don't see why the whole thing falls over when there is no start script before the build is done.
btw I am building in npm postinstall..
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.
If you are hosting an app service. Do the following after implementing all the above and the problem persists.
Most helpful comment
Why can't we choose our own start script or path? People using Typescript always compile code to
./buildor./distfolder. 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.