Multiple node_modules Installed But Not Copied to Website Production Environment

[capraynor]

There should be multiple node_modules in my project when the npm install command completed.

But not all the node_modules directory correctly copied to the production website directory.

Repro Steps:

This is my example project.

https://github.com/capraynor/kudu-bug-multiple-node-modules-not-copied-correctly

When I deployed this project to azure web app, I cannot see /home/site/wwwroot/another-directory/node_modules using ssh in advanced tools.

But I can see /tmp/the-hash/another-directory/node_modules using Bash in advanced tools

I really have no idea on this. Could you help us to figure this out? Thanks!

I'm using the following technologies:

• Azure app service Local Git
• Node.js 10.15
• Azure Linux App Service

Looking forward for your reply!

[capraynor]

Also reported in here.

projectkudu/kudu#2985

[gpcastro]

Thanks for reaching out. I can repro the issue, and we'll work on a fix. For now, disabling the performance optimizations we have for the build should make your build work. To do that, set app setting BUILD_FLAGS to "Off" (case matters, so "off" won't work"). Please let me know how it goes.

A bit of context as to why we compress node_modules: to make builds faster, we build the node_modules folder in a separate location in the container with faster disk IO, and copy its contents as node_modules.tar.gz to wwwroot, and extract its contents when running the app, also in a locatio with faster disk IO. For this app, the build is not copying the node_modules folder in a sub-directory as it should.

[capraynor]

Hi, thanks for your information.

Seems that the BUILD_FLAGS works in my case.

But here's some other problems:

When BUILD_FLAGS is removed:

• nodegit package can be installed normally
• npm dedupe works correctly

When BUILD_FLAGS is Off:

• nodegit package cannot be installed due to node-pre-gyp error.
• npm dedupe has an error with npm ERR! Cannot read property '0' of undefined.

Seems that this is caused by different npm version.

I modified my code to let it works, but I think that the BUILD_FLAGS configuration should not affect npm version and node.js version.

Kudu separates the deploy environment and production environment.

I can tell that when we set BUILD_FLAGS to Off, Oryx will build all the things by using the node in production environment, I'm I correct?

[capraynor]

Still have no idea about your flag. Your flag affects the node.js environment itself, let it not stable.

My Workaround:

I will run npm install, and move the node_modules to somewhere that oryx not discard.

And then, when the website starts, I will move that directory to node_modules. I will put this process to prestart phase.

This costs time when deploying, but works.

I will wait for your fix.

Thanks for your amazing product!

[gpcastro]

From your description, oryx might still be trying to extract node_modules when the app is starting. This will happen if oryx-manifest.toml file is present in /home/site/wwwroot. You can either remove this file, or just rebuild your application through app service (e.g. doing a git push or redeploying through VS Code)

[capraynor]

Thanks for your reply

I did rm -fr * in /home/site/wwwroot/, things still happen. node-gyp won't work correctly.

[capraynor]

npm dedupe is a known issue that never solved.

I think that the flag breaks the node.js version.

[capraynor]

The node_modules will be extracted to /node_modules, is this the expected behavior?

The result is correct, but I think this is a little strange. If a user serves node_modules as a public directory, that user will get 404 when he requesting the files in node_modules.

[gpcastro]

Yes, this is expected. You can find out more about why we do this, as well as how to disable this behavior, here: https://github.com/microsoft/Oryx/blob/master/doc/hosts/appservice.md#nodejs

[capraynor]

Well I think we can do ln -s to link the /node_modules to network volume. Just a suggestion :-D .

Do you think this is possible? Is network volume contain some limitations?

[arroyc]

@capraynor we are doing this actually and it will be published in the next release. Thank you for the suggestion, we appreciate your feedback and please keep using the product and report any issues or suggestions that you may have. For the time being I'm closing the issue

[capraynor]

Still not solved on azure app service.

[kichalla]

@capraynor what is the issue that you are seeing? could you file a separate issue with more details?

[capraynor]

#409