as you can see at the image above, locally I am using node v10.16.3, but from cloud function dashboard it seems I still using runtime node JS 8. is this ok ? or do make something wrong ?
According tho the documentation: "You have to set the version in the engines field in the package.json file that was created in your functions/ directory during initialization" link.
Please keep in mind that Node.js 10 runtime is currently in beta.
For example, to use only version 10, edit this line in package.json:
"engines": {"node": "10"}
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 am trying to deploy a firebase project (functions/hosting) and in my functions package.json, I changed the engine to node 12 because some of my other packages required it to be at least node 12 (previously it was node 10).
When I try and deploy using vscode, I get this error:
Error: package.json in functions directory has an engines field which is unsupported. The only valid choices are: {"node": "8"} and {"node": "10"}. Note that Node.js 6 is now deprecated.
After spending a few hours trying to get this to work, I was able to deploy from my terminal using firebase deploy, but it's still throwing the same error when I try and deploy directly from vscode. From the firebase documentation it seems like node 12 should be available? https://firebase.google.com/docs/functions/manage-functions#set_nodejs_version
I also ran npm install -g firebase-tools to update my firebase tools.
From the log of the failure, I am using:
2 info using npm#6.14.16
3 info using node#v12.22.12
If the package.json file in your functions dir has :
"engines": {
"node": "12"
}
Then you are fine.
Firebase supports up to Node 16.
It sounds to me like your VS Code environment has a different version of node installed than your terminal - which could also mean that you have a different (older) version of firebase-tools being used by VS Code.
To test this just run this in both your terminal and VS Code and compare the results :
node --version
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
When I deploy to Azure WebSite the node runtime correctly uses the Nodejs I config in package.json, however the deployment script uses the node and NPM on the server's path. (The Server path is messed up and has both node version in the path.)
Ex. I want nodejs 4.2.1 and NPM >2
When I deploy an app it uses 0.10.x and NPM 1.x.x. My rxjs module requires NPM > 2 so it fails to load.
If I deploy avoiding the packages I can see the correct runtime is run.
Is there a way to fix this issue?
You can simply customize the nodejs version in Azure manage portal.
In CONFIGUE tab of your web site portal, under the APP SETTINGS section, the nodejs version is set as WEBSITE_NODE_DEFAULT_VERSION to 0.10.32 by Azure default, we can directly change it value to 4.2.1 you want.
Click the restart button at bottom nav bar after you modified the site setting.
Login on your KUDU console site, you can check the nodejs version in the cmdlet.(The site URL should be: https://{your site name}.scm.azurewebsites.net/DebugConsole)
And the nodejs version is 4.2.1 with npm version 3.3.9 after modification.
You can get more info at Specifying a Node.js version in an Azure application.
There are also atleast two other mentions on various sources claiming that it can be set via package.js:
"engines": {
"node": ">= 8.2.0 || 8.x.x",
"npm": ">= 5.3.0 || 5.x.x"
},
Or via the iisnode.yaml file in the site directory root. Which one does the trick is really hard to discover since you can only tell the node version correctly during runtime of the app.
I've been using Node.js as my runtime within Bluemix for a few weeks now but I saw somewhere that there's a new version of the runtime now live on Bluemix. I have some changes to my app that need to be pushed but I'm not sure if I'm quite ready to move to the new buildpack version yet. Is there a way to use the older version of the buildpack while I complete my testing?
Yes, you can still use v1.18, as it will be available on Bluemix for a period of time and can be accessed using the CF command below:
$ cf push your_app_name -b sdk-for-nodejs_v1-18-20150519-1759
Or, you can specify the following in your manifest.yml:
buildpack: sdk-for-nodejs_v1-18-20150519-1759
All available buildpacks installed on the system can be viewed using the following command:
$ cf buildpacks
If you're concerned about the default version of Node.js moving from 0.10 to 0.12 with the buildpack updates, it is still possible to manually specify the runtime version by setting the following property in your package.json file:
"engines": {
"node": "0.10.x"
}