2
votes

I'm running a Node webapp on Azure. I deploy the app using the "local git" method. Every time I make changes to my source, commit, and then deploy with git push azure master, the code on the site is updated, as expected.

But one of my recent changes included adding a new package to my package.json file. Now when I deploy, my files are updated, but azure doesn't seem to re-run npm install, and the new modules are not installed. This means that the app doesn't start: when my code calls require('missingModuleName') it gets a fatal error and stops.

Last time I had this problem, I removed the app from Azure, and created a new one from scratch. But I hope that there's a simpler solution.

I see (at https://github.com/projectkudu/kudu/wiki/Deployment) that on deployment "For Node sites, Kudu runs 'npm install' in the wwwroot folder". I'm not sure whether the standard "local git" deployment method invokes the Kudu deployment process. Do I need to create a deployment hook (as described in https://github.com/projectkudu/kudu/wiki/Deployment-hooks)?

The installation log shows: 2017-07-29T07:59:51 Updating branch 'master'. 2017-07-29T07:59:52 Updating submodules. 2017-07-29T07:59:52 Preparing deployment for commit id '556a34aab5'. 2017-07-29T07:59:52 Running custom deployment command... 2017-07-29T07:59:52 Running deployment command... 2017-07-29T07:59:52 Command: deploy.cmd 2017-07-29T07:59:53 Handling node.js deployment. 2017-07-29T07:59:53 KuduSync.NET from: 'D:\home\site\repository' to: 'D:\home\site\wwwroot' 2017-07-29T07:59:53 Copying file: 'package.json' 2017-07-29T07:59:53 Looking for app.js/server.js under site root. 2017-07-29T07:59:53 Using start-up script server.js 2017-07-29T07:59:55 Node.js versions available on the platform are: 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.10.40, 0.12.0, 0.12.2, 0.12.3, 0.12.6, 4.0.0, 4.1.0, 4.1.2, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.0, 4.3.2, 4.4.0, 4.4.1, 4.4.6, 4.4.7, 4.5.0, 4.6.0, 4.6.1, 4.8.4, 5.0.0, 5.1.1, 5.3.0, 5.4.0, 5.5.0, 5.6.0, 5.7.0, 5.7.1, 5.8.0, 5.9.1, 6.0.0, 6.1.0, 6.2.2, 6.3.0, 6.5.0, 6.6.0, 6.7.0, 6.9.0, 6.9.1, 6.9.2, 6.9.4, 6.9.5, 6.10.0, 6.11.1, 7.0.0, 7.1.0, 7.2.0, 7.3.0, 7.4.0, 7.5.0, 7.6.0, 7.7.4, 7.10.0, 7.10.1, 8.0.0, 8.1.4. 2017-07-29T07:59:55 Selected node.js version 8.1.4. Use package.json file to choose a different version. 2017-07-29T07:59:55 Selected npm version 5.0.3 2017-07-29T07:59:56 Updating iisnode.yml at D:\home\site\wwwroot\iisnode.yml 2017-07-29T07:59:56 npm WARN lifecycle The node binary used for scripts is D:\Program Files (x86)\nodejs\0.10.28\node.exe but npm is using D:\Program Files (x86)\nodejs\8.1.4\node.exe itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with. 2017-07-29T08:00:03 npm WARN [email protected] No repository field. 2017-07-29T08:00:03 up to date in 7.206s 2017-07-29T08:00:03 npm WARN [email protected] No license field. 2017-07-29T08:00:03
2017-07-29T08:00:03 Finished successfully. 2017-07-29T08:00:03 Running post deployment command(s)... 2017-07-29T08:00:03 Deployment successful.

1
To help isolate, what happens if you manually run npm install from the site/wwwroot using Kudu Console?David Ebbo

1 Answers

2
votes

The problem was with package-lock.json. I was using an old npm version 3 locally, and it didn't create a package lock file (and I wasn't ready for shrinkwrap).

But the newer npm version 5 on Azure did create a package-lock.json. That seems to take precedence over the package.json.

So I upgraded npm locally (took a while to find that I needed nodist npm latest to do it), and added the package-lock.json to my git repo. Then when it deployed, npm took quite some time but it installed everything for me.