Migrations
Migrate from Typegoose
Move from decorators and classes to direct TypeScript schema builders
Typegoose is a wrapper around Mongoose. It keeps the Mongoose document model, but uses classes and decorators such as @prop() and helpers like getModelForClass() to make the TypeScript side easier to manage.
Mongster takes a different route. It removes the class and decorator layer entirely and keeps the schema in a plain TypeScript builder.
Concept mapping
| Typegoose | Mongster |
|---|---|
class User { @prop() name?: string } | const userSchema = M.schema({ name: M.string().optional() }) |
getModelForClass(User) | model("users", userSchema) |
@pre / @post decorators | schema.pre() / schema.post() or model.pre() / model.post() |
experimentalDecorators and emitDecoratorMetadata | not required |
A typical target shape
import { , } from "mongster";
const = .({
: .().(),
: .().(0),
: .(),
: .(.()).([]),
}).();
const = ("users", );What changes in real projects
- Class instance methods usually move into plain functions or service-layer helpers.
- Mongoose document workflows such as
doc.save()become collection-model operations likecreateOne()orupdateOne(). - Refs become explicit
M.objectId().ref(() => Model)fields when you want populate.
Why teams usually prefer this migration
- No decorator pipeline to configure.
- No metadata reflection requirement.
- No split between a class definition and the runtime schema behavior.
If your project depends heavily on Mongoose virtuals, plugins, or discriminator workflows, treat the move from Typegoose to Mongster as an architectural change rather than a rename exercise.