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
Related
My setup in GCF:
install npm install --save puppeteer from project cloud shell
edit package.json like so:
{ "dependencies": { "puppeteer": "^19.2.2" } }
paste code from medium.com into index.js:
https://gist.githubusercontent.com/Alezco/b9b7ce4ec7ee7f208818e395225fcbbe/raw/8554acc8b311a10e272f5d1b98dce3400945bb00/index.js
deploy with 2 GB RAM, 0-3 instances, max 500s timeout
I get these errors after building or opening the URL:
Internal Server Error
Could not find Chromium (rev. 1056772). This can occur if either 1. you did not perform an installation before running the script (e.g. npm install) or 2. your cache path is incorrectly configured (which is: /workspace/.cache/puppeteer). For (2), check out our guide on configuring puppeteer at https://pptr.dev/guides/configuration.
When I run npm list both webdriver and puppeteer are installed. I suspect there is an issue this Path but I cannot figure out where it should lead.
I could then provide puppeteer.launch() with argument executablePath which might solve the problem.
I tried reinstalling puppeteer and changing configuration. No luck.
In addition to adding a .puppeteerrc.cjs per Kristofer's answer, I added a postinstall script in my package.json:
"scripts": {
...
"postinstall": "node node_modules/puppeteer/install.js"
},
This fixed the problem and I was able to deploy my Google Cloud Function. This is a temporary fix until issue #9128 is fixed.
I had the exact same issue and it seems to be related to this https://github.com/puppeteer/puppeteer/issues/9128
I'm using Firebase and don't have complete control over the build process when I deploy my functions but I still have access to the build logs. From the issue above, I realized I needed to handle the cache directory and the NPM version for this to work.
As far as I can tell the problem is that the build step installs the Chrome browser needed for Puppeteer in a cache directory outside of the final image that is used for the actuall function. In that context the error message makes more sence, it can't find the browser therefor it doesn't work.
I was using Node 14 in my cloud functions which used NPM 6.14.17 in the build steps. According to the issue you need to use NPM > 7 so I upgraded my function to use Node 16.
Then I added the .puppeteerrc.cjs from https://pptr.dev/guides/configuration/#examples when testing that locally it will add a .cache directory where the Chrome installation is. This has to be ignored when deploying the cloud function or the deplot will fail due to size.
In the firebase.json add:
"functions": {
"ignore": [
".cache"
]
},
The last step is pretty specific for Firebase and I'm not sure how this applies to your build steps etc. But this solved my issue that had the exact same error messages as you had. So double check the following:
NPM version in the build step, needs to beat least v.7 - Node 16 should do this.
Cache directory specified in the .puppeteerrc.cjs
It also looks like your using an old Puppeteer version, I used 19.3
I got this same (very missleading) error in my Puppeteer project which I run in Google Cloud Function. The issue was that Function was finishing (exiting) before the async Puppeteer script was finished.
Resolved this issue by changing the "await browser.close();" to a Promise and creating the response message in promise.then().
... only to hit next problem. My script is not downloading the csv file as expected. Works locally though...
I have a previous version of node installed but after few days it gets automatically updated to the latest version. I do not want it to upgrade itself to a newer version.
You need to specify the exact node version in your package.json file.
A bit of background, from the NPM documentation:
It's important to communicate the extent of changes in a new release of code, because sometimes updates can break code that a package needs (called dependencies).Semantic versioning (semver) is a standard that was designed to solve this problem.
From your terminal, type node --version; you will get a number formatted as X.X.X
Open your package.json file and remove any ~ or ^ signs from the node version you want to use so that it won't update to any minor or batch changes.
enter npm install in your terminal again and you are done.
I am working on ember cli version 1.12 and node js version v0.12.7,I want to intergrate ember-cli-barcode addon.I have tried following:
ember install:npm ember-cli-barcode
Then it will show message that it required node version 4 >.So I have used Node version v7.0.0 stable.I installed node modules and addon.
Then tried following command:
npm install
bower install
ember server
But It will always shows errors,of node-modules etc.Kindly help me for the same how to integrate addon and which file need to change.
This should be a comment but I can't comment yet. I'm the author and it's compatible with Ember 2.4 onward. I will be putting version compatibility information in the readme.
I haven't worked with a cli version this old but ember install should be all you need if it's compatible. The add-on is a really thin wrapper around JsBarcode, so you could use the library direct if you have stay with the current ember version.
To get the benefits of the full ember-cli ecosystem, you'd have to be using the versions that support it. I think that it began in 1.13
As mentioned, it's highly likely that this addon assumes the standard CLI setup. You could ask the author.
Depending on your app complexity, you could do a few different things.
You could use the js library https://github.com/lindell/JsBarcode - (which is what the addon uses)
OR you may want to rewrite the app with the latest and greatest - now. 1.12 is going to be expensive to keep up / and since you've likely figured out how all the logic should work, then writing it again won't be the hardest part. (this sounds fun, right?) - and then use the addon
Which will take longer?
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.
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