Nodejs version on Google App Engine standard - node.js

Googles docs indicate they support the latest LTS of Nodejs, and that they support the latest version of the specified version.
https://cloud.google.com/appengine/docs/standard/nodejs/runtime
it uses the latest stable release of the version you choose.
Currently, NodeJS is on 14 for LTS, and 12.18.4 for version 12. However, App Engine Standard appears to be stuck on 12.16.3 as it's latest version.
Is there any indication of their release cadence? When can we expect an upgrade?
Motivation: I'm trying to setup a typescript monorepo with published packages & App engine. This relies package.json specifying "exports" field, but 12.16 seems not to support it, even behind the --experimental-exports tag.

I have deployed a quickstart with node12 in AppEngine Standard and had the sames results than yours, the current latest TLS for Node seems to be: v12.16.3.
I printed the version with this code:
app.get('/', (req, res) => {
res.status(200).send('Hello, world!>>'+process.version).end();
});
The result was:
This is happening also in the Flexible environment, I faced a similar issue in which is supposed to pick the latest major version, instead always pick a lower, but it is consistent on picking always the same. This seems to be a expected behavior, but it is well worth to know the reason.
I tried setting the specific version 12.18.4 but with no success.
**ERROR**: (gcloud.app.deploy) INVALID_ARGUMENT: The 'package.json' configuration file must specify a supported nodejs12 version that is compatible with the runtime specified in the deployment. Please pin your application to a compatible major version of the runtime via the 'engines.node' property. Supported 'engines.node' values for the runtime 'nodejs12' are: [12.x.x, 12.X.X, 12.x, 12.X, 12.*.*, 12.*, ~12, ~12.0, ~12.0.0, 12, ^12, ^12.0, ^12.0.0, >=12, >=12.0, >=12.0.0, >12.0, >12.0.0, >=1, >=1.0, >=1.0.0, >1, >1.0, >1.0.0, >=2, >=2.0, >=2.0.0, >2, >2.0, >2.0.0, >=3, >=3.0, >=3.0.0, >3, >3.0, >3.0.0, >=4, >=4.0, >=4.0.0, >4, >4.0, >4.0.0, >=5, >=5.0, >=5.0.0, >5, >5.0, >5.0.0, >=6, >=6.0, >=6.0.0, >6, >6.0, >6.0.0, >=7, >=7.0, >=7.0.0, >7, >7.0, >7.0.0, >=8, >=8.0, >=8.0.0, >8, >8.0, >8.0.0, >=9, >=9.0, >=9.0.0, >9, >9.0, >9.0.0, >=10, >=10.0, >=10.0.0, >10, >10.0, >10.0.0, >=11, >=11.0, >=11.0.0, >11, >11.0, >11.0.0].
I think you can file an issue in the Public Issue Tracker, I found this similar in Flexible. This issue could be related to some internal stuff architecture of App Engine. When filing the issue, provide as much information as possible, always sanitizing to avoid sharing sensitive information, such as project ID, passwords, etc.

Related

NuxtJS & Firebase : upgrading to NodeJS 16 engine breaks Firestore listener (Firebase rules)

I've been using NuxtJS (v2.15.8) with Nuxt Firebase (v7.6.1), running on NodeJS engine 12 (v12.21.0 to be exact) for the web application I've been developping incrementally for the past couple of years and my web app is now quite complex.
I am trying to upgrade NodeJS to the latest LTS version (v16.13.2) and encounter one major issue after switching version of NodeJS (using nvm) and changing the package.json of my five packages from node 12 to node 16 :
package.json :
"engines": {
"node": "16",
..
},
When running exactly the wame web application after these changes, it starts correctly but Firebase Rules seem to break, with this error FirebaseError: false for 'get' # L61, false for 'get' # L268.
It is a cryptic error, but from experience and from all I could find online, it happens when a call to Firestore that gets blocked by defined Firebase Security rules). In my case, it happens on a "onSnapshot" call to listen to the changes of the currently logged in user. Some other calls to Firestore (using "get" and not "onSnapshot") seem to work fine, and the Firebase Authentication works well too.
Here is the full error stack :
loggedInUser.js?384a:65 Error listening to user changes
FirebaseError: false for 'get' # L61, false for 'get' # L268
at new n (prebuilt-306f43d8-45d6f0b9.js?23bd:188:1)
at eval (prebuilt-306f43d8-45d6f0b9.js?23bd:10426:1)
at eval (prebuilt-306f43d8-45d6f0b9.js?23bd:10427:1)
at n.onMessage (prebuilt-306f43d8-45d6f0b9.js?23bd:10449:1)
at eval (prebuilt-306f43d8-45d6f0b9.js?23bd:10366:1)
at eval (prebuilt-306f43d8-45d6f0b9.js?23bd:10397:1)
at eval (prebuilt-306f43d8-45d6f0b9.js?23bd:15160:1)
at eval (prebuilt-306f43d8-45d6f0b9.js?23bd:15218:1)
The portion of code triggerring the error is :
listenUser({ commit }, userId) {
const userRef = this.$fire.firestore.collection('users').doc(userId);
userListener = userRef.onSnapshot(function(userDoc) {
if (userDoc.exists) {
const user = userConverter.fromFirestoreData(userDoc.data());
commit('SET_LOGGED_IN_USER', user);
}
},
function(error) {
console.error("Error listening to user changes", error);
});
},
As soon as I revert back to Node 12, the same call works fine and isn't blocked by the Firebase rules, so the error doesn't appear.
I therefore have several questions :
Does anyone understand what's happening there ? Is there known changes in the behavior of Firebase rules directly related to the NodeJS engine ?
Do you think this issue can come from Nuxt or its Nuxt Firebase module are not working correctly under NodeJS 16 ?
It is required to also upgrade NuxtJS to a newer version or should it be possible to simply update the Node Engine ?
Is it required to update to a newer version of Firebase (modular implementation) despite the Nuxt Firebase module stating :
"This module does not support the new modular syntax from Firebase v9+. If you plan to use the new modular mode of Version 9, we advise you to implement Firebase manually as described in the following medium article. It is currently unclear when, and if, this module will support the new modular mode."
Source : their Github repo
Any help to understand what's going on here is welcome !!
Thanks a lot for your help !
Regarding your questions:
I'm unaware of what is causing this issue but there are no known changes in the behavior of Firebase Rules depending on the NodeJS version you are using.
It's hard to assess without having more information. However I deployed a sample NuxtJS app following this guide on NodeJS 16 and it worked. Additionally the error code, as you mentioned, is caused when a Firestore Rule blocks a query. Therefore I think the root cause might be in the NuxtJS firebase module.
I wasn't able to find any documentation suggesting that you need to upgrade NuxtJS when upgrading NodeJS. Additionally you mentioned that you are using version 2.15.8 of NuxtJS which according to this release notes is the latest version.
I'm unsure on further support for NuxtJS considering that statement, but according to this Firebase documentation it is recommended to upgrade to version 9.
If you decide to attempt to upgrade to firebase v9 make sure to also upgrade Nuxt Firebase module to version 8.0.0 or higher, this version provides support to the compat library so you can use Firebase v9 although still with the old syntax, more information can be found here.
Lastly, if you'd like to test if a Firebase rule is working as expected you can quickly test it using the Rules Playground.
Long story short : upgrading to Firebase v9 worked.
Before I did that, I got stuck with rules preventing me to access firestore documents as soon as I tried running the project under Node16 engine.
So I had to do the following changes :
updating Firebase to v9
implement the configuration through a plugin rather than the nuxt-firebase module
make all the required changes in my code to make use of v9 modular (I didn't try using the compat version)
Now that I use the latest version of Firebase, I tried again switching to NodeJS 16 and it runs fine, including the Firebase security rules.

node, azuresb.createServiceBusService provide connection string instead of environment variable

I'm using the package azure-sb to send a message to an Azure Service Bus topic. My problem is that the constructor expects a key for a connection string for example
azuresb.createServiceBusService(KEY_NAME)
Is it possible to provide the connection string itself instead of a KEY_NAME?
Yes, you can. From the documentation of this package, you do need to pass the connection string.
var connStr = process.argv[2] || process.env.CONNECTION_STRING;
var sbService = azure.createServiceBusService(connStr);
Microsoft Azure SDK for Node.js - Gallery https://www.npmjs.com/package/azure-sb
Also, azuresb seems an older SDKs. If you use Azure SDK for Node.js, here is how you can pass the connection string (quite similar!)
var serviceBusService = azure.createServiceBusService(connectionString)
You might have found the answer already... adding it here if someone else visits your question in future. :)
As mentioned in the other answers, you can pass the connection string. Your code seems to be using the older azure-sb library.
I'd recommend using the latest #azure/service-bus library which is based on AMQP protocol and is more performant.
I know this is a late reply, but just in case someone is running into issues with the older service-bus node SDK and landed here, refer to the links below.
The latest version 7.0.0 of #azure/service-bus has been released recently.
#azure/service-bus - 7.0.0
Samples for 7.0.0
Guide to migrate from #azure/service-bus v1 to v7

LoginApi ERROR Restsharp.addfile

Currently using RestSharp V106.1.0 as well a v2.1.8
While attempting to integrate docusign with our application I received an error off of the loginAPI:
string accountId = loginApi(username, password, integratorKey);
Receiving this error
{"Method not found: 'RestSharp.IRestRequest RestSharp.RestRequest.AddFile(System.String, System.Action`1, System.String, System.String)'."}
I have verified all of the parameters have the correct value and I was able to recreate a working API usage in a brand new project without prior packages installed. This leads me to think it is the version of RestSharp that is giving me this issue.Based on research about others having this issue it was an issue of the library change within updates.
Is there a specific version that is required as the dependancies for Docusign Package in visual studio doesn't mention a Restsharp version requirement?
Thank you in advance.

Bluemix node.js doesn't like "=>"

I'm new to Bluemix and node.js. I'm creating a Bluemix app that integrates with Box, but the built in Box service uses out-of-date node.js support, and I'd like to use the most recent node.js Box SDK.
I'm including this line at the top of my code
var BoxSDK = require('box-node-sdk');
But in processing this SDK, the log file throws an error on this line (line 191 of box-node-sdk/lib/api-request.js):
this.stream.on('error', err => this.eventBus.emit('response', err));
The error is:
SyntaxError: Unexpected token =>
What do I need to do to get Bluemix's node.js to recognize this (apparently new) syntax?
After some further digging, I discovered this page in the Bluemix runtime documentation, which says:
A node version should always be specified in the package.json file. If it is not, the latest node version will be used.
I removed the engines{} section from my package.json file to force it to use the latest node version, and I've gotten past this problem. (On to my next error...)
Thanks very much to jfriend00, who gave the crucial information that led me where I needed to go!

Validating array items with joi in a Foxx app

I am having problems with using joi array-item validation in foxx applications as well as the arango-shell with arangodb-2.5.5.
The joi-documentation suggests to use something like:
var Joi = require('joi');
Joi.array().items({'name': Joi.string().required()});
for validating a dataset similar to:
[{'name': 'Peter'}, {'name': 'Edeltraut'}, ...]
However, using it in a Foxx application results in the application to stop working. Pasting the snippet from above into the arango-shell produces the following output:
JavaScript exception: TypeError: undefined is not a function
!Joi.array().items({'name': Joi.string().required()});
! ^
stacktrace: TypeError: undefined is not a function
at <shell command>:1:13
Is there something I am missing, or is arangodb using a modified / smaller version of joi that has this feature stripped out?
ArangoDB 2.5 uses an older version of joi. The method in question was renamed to items in joi 6.0 and was previously called includes.
You can find the documentation for joi 4.9.0 (the version shipped with ArangoDB 2.5) at https://github.com/hapijs/joi/tree/v4.9.0
ArangoDB 2.6 will ship with joi 6.4.3, which is the latest version at this time.
If you want to know the version of an NPM dependency shipped with ArangoDB, you can also find out the version number by importing its package.json file like this:
require('joi/package.json').version
You don't have to wait for ArangoDB 2.6 to use the latest version of joi. If you npm install joi --save inside of your Foxx app's APP folder, it'll be used instead of the one bundled with ArangoDB. I've been doing that for a while now.

Resources