node js on azure - deeply nested node modules cause error - node.js

I'm using a node module called swagger-tools, which internally depends on lodash. When swagger tools is installed, the depth of its node_modules folder is very big, which causes an error on my azure web app (a Windows server). I saw somewhere that this problem can be solved by using npm 3, and while npm 3 is installed on azure server, I can't force it to use it - the error logs indicate that npm 2 is being used. This is how I do it in package.json:
"engineStrict": true,
"engines" : {
"npm" : ">=3.0.0"
}
The node version is 4.4.7.
If anyone knows about a different way to fix the issue I will be glad.

you are correct that NPM 3 should solve the issue because it uses flat file system and not nested dependencies in which windows file system doesn't support well.
To force NPM 3 it really depends on your publish method (git/vs).
Here is a guide for forcing NPM 3 -
https://blogs.msdn.microsoft.com/azureossds/2015/09/13/npm3-on-azure-web-apps/

Set the npm path to the absolute location to the npm 3 on Azure Web Apps file system in Custom Deployment Script as described by #shachar will be a solution.
And additionally, there is a easier workaround. You can define the nodejs version in your package.json to the version which contains the npm 3. The lowest nodejs version which contains npm3 is 5.0.0.
So, you can simply modify the engines section in your package.json:
"engines" : {
"node" : "5.0.0"
}
You can refer https://azure.microsoft.com/en-us/documentation/articles/nodejs-specify-node-version-azure-apps/ for more info.

Related

Cannot update the AWS-SDK package in node.js

To this make easier I created a fresh node.js application on VS code. The only package/dependency I install is AWS-SDK. in my package.json the version is shown as "aws-sdk": "^2.1314.0",
as far as I am aware the most recent version is 3.270.0. my node.js version is v14.18.1.
I have manually edited pakage.json to reflect the new version then done npm install aws-sdk again, doesnt work. sometimes it reverts back to 2.1314.0, sometimes the version I added remains but npm aws-sdk list command still shows old version
Hope this is enough information! Thanks
First of all stop using version 2 of aws sdk as it is planned to go into maintenance mode from 2023
Second from version 3, you only use you load and use only the individual AWS Services you need to save the the size of code.
if you need to use only a few AWS services, it means increasing the size of your application with code you don't need or use.
For example to use fynamodb package in version 3 you will use use
npm i #aws-sdk/client-s3
Coming to your question
delete node modules directory
npm cache clean --force
just simple remove the entry in your package.json and add entry like this
"dependencies": {
"#aws-sdk/client-s3": "^3.256.0"
}
npm i #aws-sdk/client-s3
For reference on aws sdk v3 - https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/welcome.html

NodeJS unexpected strict mode reserved word "let" when installing ejs (not my code)

I'm getting this output when trying to install a node application using npm install:
$ npm install
> ejs#2.7.4 postinstall /home/dh_8u42k7/quotegoodeair.com/node_modules/ejs
> node ./postinstall.js
/home/dh_8u42k7/quotegoodeair.com/node_modules/ejs/postinstall.js:9
let envDisable = isTrue(process.env.DISABLE_OPENCOLLECTIVE) || isTrue(process.
^^^
SyntaxError: Unexpected strict mode reserved word
I have already found this question which contains a workaround. However, this isn't my own code, so I can't just remove "let", it seems to be a problem with ejs itself.
For another thing, the file postinstall.js doesn't even exist, even the ejs folder doesn't exist, so I can't just go in and edit the file.
Is there something wrong with my node application, or with ejs, or maybe with npm or Node itself? Why does Node install components which aren't supported by Node? Why does Node tell me there's an error in a file which doesn't exist?
It may be that your version of node does not support the features in the application you are trying to install.
One solution may be to find out what the version of node the application that you are trying to install originally used.
I believe you can check the engine field in your package.json file.
If you local node version is different, and you need to change it, here is a link to a question providing that information: How can I specify the required Node.js version in package.json?
I also found this post interesting: https://github.com/tj/n/issues/472
It's for a different application but they received the same error message. The issue was conflicting npm folders. It's possible that the program that you are trying to install is conflicting with your existing npm setup if you have other nom folders in the directory you are installing the application in.
Ultimately, given the information you provided, I think your best bet it to look in the package.json file of the application you're trying to install and see if your local setup is conflicting with how the program is trying to be installed or run.

How to npm configuration options (such as --scripts-prepend-node-path) when deploying to azure web sites?

I used following in package.json when deploying to azure web site:
{
"name": "mypackage",
...
"engines": {
"node": "6.11.1",
"npm": "4.2.0"
},
...
}
Everything worked fine but I also got following warning:
npm WARN lifecycle The node binary used for scripts is D:\Program Files (x86)\nodejs\6.9.1\node.exe but npm is using D:\Program Files (x86)\nodejs\6.11.1\node.exe itself. Use the --scripts-prepend-node-path option to include the path for the node binary npm was executed with.
Finished successfully.
How do I set this --scripts-prepend-node-path option when deploying to azure web sites?
You can set this option by using npm config set scripts-prepend-node-path true when deploying to Azure.
In your Azure App settings, try setting WEBSITE_NODE_DEFAULT_VERSION to 6.11.1 so it matches your engine spec. Though I'm guessing the warning is mostly harmless.
Though the above should solve your issue, to more directly answer your question, you can add npm params by creating a Custom Deployment Script. Specifically, you'd look for a line that looks like call :ExecuteCmd !NPM_CMD! install --production and modify it whichever way you need.

Azure and node js __dirname

Probably it is not specifically related to webpack/memory-fs, but I am getting the RangeError: Maximum call stack size exceeded error (see below for a call stack).
I have found out, that __dirname on Azure (webapp) returns \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\memory-fs\lib\normalize.js in my situation, while process.cwd() returns D:\home\site\repository\Source\Website\Content\app.
Is anything can be done from my side to configure node js to return D:\... instead of \\.. ?
Gist
How to reproduce:
Clone the https://github.com/intellismiths/webapp1 repository.
Create new Azure Web App (default settings).
Configure deployment source to use GitHub.
Click Sync. It will take 10+ minutes to complete and it will show that the deployment was successful.
Go to Application settings in Azure and change WEBSITE_NODE_DEFAULT_VERSION to 6.2.2
Go to kudu page and open powershell console.
Execute npm cache clean
Check node version by executing node -v. It should be v6.2.2
On Azure, navigate to D:\home\site\respository\src\WebApp1
Execute npm run build
In console, you should see a lot of errors which indicates that modules can not be resolved.
OPTIONAL. Test npm run build on your local machine - it should produce wwwroot/app.js without errors.
Update webpack.config.js to include context: __dirname to fix previous errors.
Execute npm run build
In console, you should see the "RangeError: Maximum call stack size exceeded" error.
Update 1
I only tried to set 6.2.2 runtime after adding the second package.json, so the project structure is not the simplest possible. Maybe just setting node to 6.2.2 breaks the build.
I could reproduce your issue following your steps. I found the key point was setting the WEBSITE_NODE_DEFAULT_VERSION to 6.2.2. And I found the webpack task worked fine if the WEBSITE_NODE_DEFAULT_VERSION was under 6.
Please downgrade the setting WEBSITE_NODE_DEFAULT_VERSION to the version under 6 e.g. 5.9.0 if your node.js modules do not need such high version.
And according the package.json of angular2 athttps://github.com/angular/angular/blob/master/package.json, it seems that the angular2 repository requires the node.js version between 5.4 and 6.
Additionally, the web application's root directory on Azure Web Apps is D:\home\site\wwwroot. So if you want to build your frontend project on Azure Web Apps, you need to locate to D:\home\site\wwwroot\wwwroot\mobile-web-app then run npm run build.
It's been fixed in master and it's proposed to be included in v6.4.0.
See: https://github.com/nodejs/node/issues/7175#issuecomment-239824532 and https://github.com/nodejs/node/pull/8070
After a long day of research, trial-and-error and various experimentation, I've found an acceptable workaround if you're not willing to downgrade to Node 5.*:
Downgrade to Node 6.1.0
Make sure to install webpack globally (with npm install -g webpack).
Just using 6.1.0 gets around the "maximum call stack size exceeded" error, but instead gave me a lot of resolve failures when running webpack from node_modules (using ./node_modules/.bin/webpack). Installing webpack globally finally got me past that.
If I understand it correctly, this whole issue with __dirname in Node >= 6.2 resolving to the UNC folder path instead of the mounted path is going to be fixed, there's an active discussion here.
I had the same issue.
Fixed it with UPGRADING npm not DOWNGRADING.
Bug is fixed in the npm versions newer than 6.5.
https://github.com/aumanjoa/chronas-community/blob/master/package.json#L48
I believe that your __dirname shows your persistant drive where the data is stored, while .cwd gives current directory from where node ran. This is because Azure runs from the Drive but files are stored at the persistent drive.
In your Gruntfile.js add
module.exports = function (grunt) {
grunt.file.setBase(__dirname);
// Code omitted
}
Refer: link

Failed to install npm

I updated to TACO 10 & VS 2015 2. I am getting the following error due to a long path.
1> Installing npm 2.14.9. This could take a few minutes...
1> Failed: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Is there any way to tell VS to use the globally installed npm. I tried installing .NET Web Development and Tools Blog and changing the path orders on the External Web Tools options.
I also tried unchecking the use sandbox node but VS still tries to install npm.
Any ideas?
Windows doesn't like the way npm would do the nested dependency trees in npm v1.x & v2.x, eventually they will throw this error. The nested dependency trees will create very long path names and will hit a cap in windows.
You should instead use npm v3.x, npm went to a flat dependency structure with v3.x and this issue will go away.

Resources