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.
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.
here's the problem.
I've wrote an app with tlg module. LINK GITHUB
I've developed using Mac Os and everything worked fine but when i've tried to move all the app to a new Centos 8 VM, recompiling TDlib and launcing the app, here's the response after the app crash.
[ 0][t 4][1588032092.051109791][Status.h:191][!Td]
Unexpexted Status [Error : 0 : Too much data to fetch at 8] in file
/td/td/telegram/Global.cpp at line 77
This is weird, i've never seen an error like this. Here's the Global.cpp
You probably used your app with a newer TDLib version and then came back to the old version, so the old td can't work with upgraded DB. So just stick with the new version.
A Brief Backstory
I have been implementing several upgrades to an Angular 8 application such as server-side rendering, and Google Analytics. As most developers do, I would code then test then move on to the next task. Typically I use ng serve to run the application as I am developing.
With Server-side rendering, to test speed, lazy-loaded images, etc, you need to use a node express server running on a generated JS file. After building, etc, I use Node prerender (my js file is prerender.js) to see what the application will look like prerendering on the server.
When I run this command, I should not get any errors, and I know my prender file will start a local server on port 4000.
The Problem
I get errors when running a node express server that I do not get when running with ng serve I recently got an error that said:
Unhandled Promise rejection: Cannot read property 'subscribe' of undefined ; Zone: <root> ; Task: Promise.then ; Value: TypeError: Cannot read property 'subscribe' of undefined
at new ApplicationRef (C:\4towerdevelopment\dist-stage\server\main.js:45910:37)
at _createClass (C:\4towerdevelopment\dist-stage\server\main.js:37184:20)
at _createProviderInstance (C:\4towerdevelopment\dist-stage\server\main.js:37138:26)
at initNgModule (C:\4towerdevelopment\dist-stage\server\main.js:37044:32)
at new NgModuleRef_ (C:\4towerdevelopment\dist-stage\server\main.js:38176:9)
at Object.createNgModuleRef (C:\4towerdevelopment\dist-stage\server\main.js:38159:12)
at NgModuleFactory_.create (C:\4towerdevelopment\dist-stage\server\main.js:50821:25)
at C:\4towerdevelopment\dist-stage\prerender.js:29175:43
at ZoneDelegate.invoke (C:\4towerdevelopment\dist-stage\prerender.js:481:26)
at Object.onInvoke (C:\4towerdevelopment\dist-stage\prerender.js:28683:33) TypeError: Cannot read property 'subscribe' of undefined
at new ApplicationRef (C:\4towerdevelopment\dist-stage\server\main.js:45910:37)
at _createClass (C:\4towerdevelopment\dist-stage\server\main.js:37184:20)
at _createProviderInstance (C:\4towerdevelopment\dist-stage\server\main.js:37138:26)
at initNgModule (C:\4towerdevelopment\dist-stage\server\main.js:37044:32)
at new NgModuleRef_ (C:\4towerdevelopment\dist-stage\server\main.js:38176:9)
at Object.createNgModuleRef (C:\4towerdevelopment\dist-stage\server\main.js:38159:12)
at NgModuleFactory_.create (C:\4towerdevelopment\dist-stage\server\main.js:50821:25)
at C:\4towerdevelopment\dist-stage\prerender.js:29175:43
at ZoneDelegate.invoke (C:\4towerdevelopment\dist-stage\prerender.js:481:26)
at Object.onInvoke (C:\4towerdevelopment\dist-stage\prerender.js:28683:33)
The closest this gets me to figuring what actually is causing the problem is letting me know that a provider somewhere is causing this error. Looks like something should be an observable rather than a subscription. Beyond that, I guess I just start looking through my providers. My question is:
How can I force Angular to possibly throw this error when developing using ng serve?
If I can't, is there a better way to debug this current error besides combing through each provider? Or at least a way to tell what service is causing the issue?
Thank you.
UPDATE: Basic repo with problem here. I made a new angular project, made sure dependencies were up to date, installed ngUniversal per this post, and received this same Unhandled promise message when running node prerender
Verbatim I went to to the Angular cli website, made a new project (default Angular version installed was 8.3), installed Angular Universal, and tried to build. Same error message as above.
This looks like it was ApplicationRef that triggered the error, and that class is provided internally by the Angular core.
It could be failing in the constructor of the class, and there are a few calls to subscribe on Zone observables. I don't think you're going to find anything in your source code that directly relates to this error. It looks like a build configuration problem.
https://github.com/angular/angular/blob/bb52fb798c8578c461d21aee2b7623232184a5d3/packages/core/src/application_ref.ts#L562
I do not know what could possibly produce this problem, but I would start a new project with SSR and compare the differences to your current project.
Eventually, I dropped the angular 6 approach using pre-render, and went with the latest universal package. There seems to be no problem building using npm run build:ssr and serving dist/server.js in an express server. I am not sure what the problem was with the pre-render approach, but it seems to be outdated anyways. #Reactgular thanks for the feedback.
I'm building an electron app that needs an open/save dialog window.
I'm following this guide online: Standard Dialogs in Electron which uses the remote package.
I'm getting a syntax error with one of the dependency files within the remote package, shown below:
Unexpected token >: node_modules/remote/libs/remote.coffee:8
Line 8 is module.exports = (opts = {}) ->, probably supposed to be =>. If I change that, I get an Unexpected identifier error instead. This leads me to think there's some kind of ES6 support issue here.
Are there any troubleshooting steps I could take to help narrow down the issue?
Or alternatively, suggestions for a different electron-compatible package for open file/save file dialog windows (mac).
This error was caused by an update issue regarding the require syntax. The solution is the following:
// use these lines instead to set up dialog instead of the remote package.
const remote = require('electron').remote;
const dialog = remote.dialog;
Fix courtesy of this Github comment