I'm encountering this weird message out of blue on my Node server (Express + GraphQL) in the terminal window. Message doesn't say where it comes from.
Anyone experiencing this problem or any idea why it's happening?
Github Issue in Typegoose Repository
Typegoose is changing how it handles enum properties, and the old behaviour is deprecated.
Check for breaking changes
If you are working on an existing project, then review the documentation to ensure your app and DB will be compatible with the new behaviour:
Enum properties
useNewEnum flag
Opt-in to the new enum behaviour
Run the following as early as possible in your start-up code:
import { setGlobalOptions } from "#typegoose/typegoose";
setGlobalOptions({
globalOptions: {
useNewEnum: true,
},
});
If you still get the warnings, then try the following:
Ensure the code is running before any other app start-up logic
Run the code before any other imports
Related
I'm building a NextJs application which uses a set of abstractions to enable code from both react (Component logic etc.) and node (API logic) to utilize same types and classes. The motive here is to make the development process seem seamless across client side and server side.
For example. a call on User.create method of the User class will behave differently based on the runtime environment (ie. browser or node) - on the browser, it will call an api with a POST request and on server it will persist data to a database.
So far this pattern worked just fine, and I like how it all turned out in terms of the code structure. However, for this to work, I have to import modules responsible for working on the server and browser to a single module (which in this case is the User class) this leads to a critical error when trying to resolve dependencies in each module.
For example I'm using firebase-admin in the server to persist data to the Firebase Firestore. But it uses fs which cannot be resolved when the same code runs on the browser.
As a work around I set the resolve alias of firebase-admin to false inside the webpack configuration (given it runs on browser) see code below.
/** next.config.js **/
webpack: (config, { isServer }) => {
if (!isServer) {
// set alias of node specific modules to false
// eg: service dependencies
config.resolve.alias = {
...config.resolve.alias,
'firebase-admin': false,
}
} else {
// set alias of browser only modules to false.
config.resolve.alias = {
...config.resolve.alias,
}
}
While this does the trick, it won't be much long until the process gets really tedious to include all such dependencies within resolve aliases.
So, my approach to this is to write a script that runs prior to npm run dev (or manually) that will read all dependencies in package.json and SOMEHOW identify packages that will not run on a specific runtime environment and add them to the webpack config. In order to this, there should be a way to identify this nature of each dependency which I don't think is something that comes right out of the box from npm or the package itself.
Any suggestion on how this can be achieved is really appreciated. Thanks`
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.
Installed the google cloud pub sub following instructions from the following link,
https://cloud.google.com/pubsub/docs/reference/libraries
Imported that as the following,
const { PubSub } = require("#google-cloud/pubsub");
const projectId = "projectXYZ";
const pubSubClient = new PubSub({ projectId });
export async function publishMessage(topicName, data) {
return await pubSubClient.topic(topicName).publish(JSON.stringify(data));
}
this leads to the following error,
Now, what I have observed is that the code below the import has no significance in this issue, since this error still appears even if I only import on the first line.
Am I missing something or required to install something more that just the package?
Any help is deeply appreciated.
Thank you in advance.
Library maintainer here! I'm guessing from the stack trace that you're using webpack on your app? Right now we don't have webpack and rollup support - there are a few weird things like what you see above. Your code looks okay. We'd like to get webpack and similar tools working at some point for server-side usage, but it hasn't gone very high on the priority list just yet. I think the previous assumption was that people were trying to use it in a web browser, which we don't recommend for a number of reasons (most prominently, security concerns with GCP credentials). But I've been seeing a lot of issues with users trying to use webpack on the server side to make their Cloud Functions more compact, which seems pretty legit. I'll bring it up in our next team sync.
If you're not using webpack, then that sounds like something that might be filed over at the issue tracker.
I just decided to upgrade an existing Sails project to 1.0.0 and managed to get through most of the upgrade process until I tried connecting to the database. When attempting to lift this is the error I receive:
The adapter used by the default datastore is not compatible with
the current version of Sails/Waterline.
The adapter should expose a valid adapterApiVersion.
If you're using the beta release of Sails 1.0, try:
npm install --save sails-disk#beta
My datastores.js file contains the following:
module.exports.datastores = {
// In previous versions, datastores (then called 'connections') would only be loaded
// if a model was actually using them. Starting with Sails 1.0, _all_ configured
// datastores will be loaded, regardless of use. So we'll only include datastores in
// this file that were actually being used. Your original `connections` config is
// still available as `config/connections-old.js.txt`.
'developmentPostgres': {
adapter: require('sails-postgresql'),
url: process.env.postgresHost,
user: process.env.postgresUser,
password: process.env.postgresPassword,
database: process.env.postgresDatabase
}
};
Where all of the values are provided as environment variables. "sails-postgresql": "^1.0.0" is installed and saved in package.json
models.js also contains the following line: datastore: 'developmentPostgres', which to my understanding means that all of my models should be using the above database by default.
Up until this point the upgrade process has been very straightforward. I assume I am just missing something simple here as well. I would appreciate any insight anyone can provide and would be happy to provide any additional information as well.
Turns out the project looks for a datastore labeled default. Changing the name to default in both datastore.js and model.js solved the issue.
I am trying to switch a hosted worker process in Azure to use xml serializer instead of the default json serializer. I have done this by implementing IWantCustomInitialization like this:
public class BusInitialization : IWantCustomInitialization
{
public void Init()
{
Configure.Instance.XmlSerializer();
}
}
However when I start the cloud solution, I get the following error:
Exception when starting endpoint, error has been logged. Reason: Type NServiceBus.Unicast.Transport.CompletionMessage was not registered in the serializer. Check that it appears in the list of configured assemblies/types to scan.
When I use no custom initialization and it goes to JsonSerializer, everything is fine. Does anyone have a suggestion where shall I look to? I use NSB 3.2.8.
thought this was fixed but I just checked, looks like in 3.2.8 the jsonserializer cannot yet be overriden easily. This has already been fixed on the dev branch but didn't get into release yet, it will be in the next one than.
If you can't wait for next release then you can work around this by replacing the AsA_Worker with your own role and role handler similar to this:
3.2.8 version https://github.com/NServiceBus/NServiceBus/blob/master/src/azure/Hosting/NServiceBus.Hosting.Azure/Roles/Handlers/WorkerRoleHandler.cs
develop version https://github.com/NServiceBus/NServiceBus/blob/develop/src/azure/Hosting/NServiceBus.Hosting.Azure/Roles/Handlers/WorkerRoleHandler.cs
Kind regards,
Yves