zip deployment with NodeJs/NPM project.

[PatrickQuintal]

Issue:
When doing zip deployment with node_modules already installed, this causes file copy issues.

Any package published with npm GREATER THEN 5.6.0 causes files within the package to have their timestamp reset to "October 26 1985"

npm will also touch the package.json on an npm install, causing the project to have a different package.json then whats actually installed. Meaning no errors get generated and you get left with a broken installation

An actual production example is:

1. I've installed hapijs 17.0.0, and deployed it via zip deploy,
2. I upgrade to 17.6.0, This deploys fine, even though this is the first version that uses a new NPM.
3. I upgrade to 17.8.1, and deploy. This time, an error gets thrown since in between those versions, they've removed a package but the code never got updated due to the timestamps being the same and it still tries to reference the old package.

Kudu Zip Deployment behavior
zip deployment
"Efficient file copy: Files will only be copied if their timestamps don't match what is already deployed. Generating a zip using a build process that caches outputs can result in faster deployments."

npm issue:
October 26 1985

tl;dr
zip deployment does not work with packages published using anything above npm 5.6.0, however, no errors get thrown and it doesn't "fail" leaving you with an incorrect install.

I realize there isn't much we can do, since this is a poor decision by the NPM team, but I figured I'd post it here so everyone is aware and potentially we can mitigate it... and also so that people don't spend hours trying to figure why their application wouldn't run on Azure 😭

[PatrickQuintal]

Sounds like the same issue here.

I'm leaving this one opened as I've referenced to it via
Feedback Forum

[JasonFreeberg]

HI @PatrickQuintal, which OS are you using, and was it a function app or a classic web app?

[PatrickQuintal]

HI @PatrickQuintal, which OS are you using, and was it a function app or a classic web app?

My OS is windows, the app OS is also windows.

I experience the issue on Web apps, I would presume Function apps are the same since they work functionally (lol) the same in terms of deployment.

One thing I can say is, I've worked around the issue by using "run from package", which effectively mounts the zip as the directory to run from. I think this is the best solution. (With the bonus side effect of disabling app service editor 😂 )

My biggest worry right now is that multiple node developers are using zip deploy, and they installations are incorrect/vulnerable.

[PatrickQuintal]

@suwatch

A bit more information would of been nice :P

I assume this gets activated by setting
SCM_ZIPDEPLOY_DONOT_PRESERVE_FILETIME to 1 on the webapp?

[suwatch]

See https://github.com/projectkudu/kudu/wiki/Deploying-from-a-zip-file-or-url#issues-and-investigation. Note that the ETA for this to go live in 4 weeks.

[billti]

Hi @suwatch. Our team just hit this. We've been deploying to prod for quite a while before we noticed this and then found the note at the bottom of https://github.com/projectkudu/kudu/wiki/Deploying-from-a-zip-file-or-url#issues-and-investigation after quite a bit of troubleshoot and searching.

This seems like a big security risk, and I think that setting should be the default. We often bump package versions purely to address flagged security issues in packages (which are hard to test for), as I'm sure others do. Without being aware of this issue, most folks probably don't even know those package bumps aren't getting updated on their site when they deploy, and the security issues still remain.

Being that NPM has made it clear this is by design and they are not going to change the file timestamp behavior, it seems recopying the files is the only way this can be mitigated, and not continue to do the current surprising erroneous behavior. Thanks.

[PatrickQuintal]

@billti I no longer work with the Azure platform in my day-to-day, but I strongly recommend to just swapping to "run from zip" instead of deploying a zip the traditional way.

I'm not sure if this was fixed, but last I tried using the flag to ignore the timestamps, deploying took an incredible amount of time.