Migrations
Migrate from Papr
Move from Papr to Mongster while keeping the driver-first mindset
If you use Papr today, the mental model is already close to Mongster. Both libraries stay near the official MongoDB driver instead of building a large document runtime.
The main difference is where the schema logic lives and what the library layers on top:
- Papr centers on
schema()andtypes.*helpers with JSON Schema validation. - Mongster centers on
M.*builders with runtime parsing, type inference, typed populate, hooks, and a typed aggregation builder.
Concept mapping
| Papr | Mongster |
|---|---|
const papr = new Papr() | const client = new MongsterClient() or use the exported mongster |
papr.model("users", schema(...)) | client.model("users", M.schema(...)) |
types.string({ required: true }) | M.string() or M.string().optional() when it is not required |
| JSON Schema-driven validation | Schema parsing and validation from the builder itself |
A typical target shape
import { , } from "mongster";
const = new ();
const = .({
: .().(1),
: .().(1),
: .().(0).(),
}).();
const = .("users", );What usually changes in real code
- Replace Papr's schema and type helpers with
M.*builders. - Keep your query filters close to MongoDB syntax.
- Move relation-like fields to explicit
M.objectId().ref(() => Model)declarations when you want populate. - Use
aggregate()instead of dropping to raw pipelines immediately when a typed builder helps.
Good reasons to switch
- You want refs and populate to be first-class.
- You want schema and model hooks.
- You want more type help around aggregation without abandoning MongoDB pipelines.