Models ref each other error: circular dependencies problem - node.js

Question

admin.model.ts
import mongoose, { Schema, Document } from 'mongoose';
import UserRole, { IUserRole } from './user-role.model';
export interface IAdmin extends Document {
role: IUserRole;
}
let adminSchema = new Schema<IAdmin>({
role: {
type: Schema.Types.ObjectId, ref: UserRole
}
});
export default mongoose.model<IAdmin>('Admin', adminSchema);
user-role.model.ts
import { Schema, Document, model } from 'mongoose';
export interface IUserRole extends Document{
updated_by: IAdmin|string;
}
let userRoleSchema = new Schema<IUserRole>({
updated_by: {
type: Schema.Types.ObjectId, ref: Admin
}
})
export default model<IUserRole>('UserRole', userRoleSchema);
MongooseError: Invalid ref at path "updated_by". Got undefined
at validateRef (/home/ess24/ess-smartlotto/node-rest/node_modules/mongoose/lib/helpers/populate/validateRef.js:17:9)
at Schema.path (/home/ess24/ess-smartlotto/node-rest/node_modules/mongoose/lib/schema.js:655:5)
at Schema.add (/home/ess24/ess-smartlotto/node-rest/node_modules/mongoose/lib/schema.js:535:14)
at require (internal/modules/cjs/helpers.js:88:18)
[ERROR] 22:25:54 MongooseError: Invalid ref at path "updated_by". Got undefined
Here is my two model how can I solve this type of problem and how to deal with circular dependencies?

Answer 1

You have to put the ref values for UserRole and Admin in '' like this:
const adminSchema = new Schema<IAdmin>({
role: {
type: Schema.Types.ObjectId, ref: 'UserRole' // Name of the model you are referencing
}
});
let userRoleSchema = new Schema<IUserRole>({
updated_by: {
type: Schema.Types.ObjectId, ref: 'Admin' // <- and here
}
})

Answer 2

While the above answer by #gabriel-lupu is correct, in newer versions it seems another fix is recommended.
Fix:
adding quotes: ref: 'UserRole' // Recommended first fix
adding an arrow function: ref: () => UserRole
Typegoose documentation says the following:
Options ref and type can both also be defined without () =>, but is generally recommended to be used with.
If () => is not used, there can be problems when the class (/ variable) is defined after the decorator that requires it. Section in documentation for reference.
Because of the order classes are loaded and reordered at runtime, this might result in some references being null / undefined / not existing. This is why Typegoose provides the following:
class Nested {
#prop()
public someNestedProperty: string;
}
// Recommended first fix:
class Main {
#prop({ ref: () => Nested }) // since 7.1 arrow functions can be used to
defer getting the type
public nested: Ref<Nested>;
}
// Not recommended workaround (hardcoding model name):
class Main {
#prop({ ref: 'Nested' }) // since 7.0 it is recommended to use "console.log(getName(Class))" to get the generated name once and hardcode it like shown here
public nested: Ref<Nested>;
}
Section of documentation with the above example
Explanation:
The MongooseError: Invalid ref at path "updated_by". Got undefined error seems to be due to a circular dependency.
IAdmin has a role property that references IUserRole.
IUserRole has an updated_by property that references IAdmin.
When admin.model.ts loads it imports user-role.model.ts
user-role.model.ts needs IAdmin for the updated_by property from admin.model.ts
admin.model.ts hasn't finished loading yet resulting in updated_by which references it being undefined.
Relevant explanation from Mozilla about how modules deal with circular dependencies.
In a cyclic dependency, you end up having a loop in the graph.
Usually, this is a long loop. But to explain the problem, I’m going to
use a contrived example with a short loop.
A complex module graph with a 4 module cycle on the left. A simple 2
module cycle on the right.
Let’s look at how this would work with CommonJS modules. First, the
main module would execute up to the require statement. Then it would
go to load the counter module.
A commonJS module, with a variable being exported from main.js after a
require statement to counter.js, which depends on that import
The counter module would then try to access message from the export
object. But since this hasn’t been evaluated in the main module yet,
this will return undefined. The JS engine will allocate space in
memory for the local variable and set the value to undefined.
The message variable will be initialized and added to memory. But
since there’s no connection between the two, it will stay undefined in
the required module.
If the export were handled using live bindings, the counter module would see the correct value eventually. By the time the timeout runs, main.js’s evaluation would have completed and filled in the value.
how module imports work
Both? fixes seem to create a live binding.
Closures can close over imported values as well, which are regarded as live bindings, because when the original value changes, the imported one changes accordingly.
// closureCreator.js
import { x } from "./myModule.js";
export const getX = () => x; // Close over an imported live binding