Seeders

Seeders A seeder puts rows in a table. Migrations change the shape of the database; seeders fill it — reference data a fresh install cannot work without, and fixtures a developer wants and production must never see. They share the migrations' machinery: the same QueryInterface, the same "run each one once" bookkeeping, and the same up/down pair. A seeder file up is what running the seeder does; down is what undoing it does. Both get the QueryInterface and the Prorm instance, so a seeder can use models instead if that reads better: In TypeScript, createSeeder() is the same object with the types filled in: Running them From the CLI: Or in code, which is what the CLI does: Each seeder runs once. The names of the ones that have run are kept in a PrormData table, created on demand; seedsTableName renames it. --force re-runs one, and only in combination with --name, so nothing re-seeds a whole database by accident. force re-runs up() as written — it does not undo first. A seeder that inserts fixed ids will collide with itself on the second run, so either undo it before forcing, or write an up() that tolerates being run twice. Keeping fixtures out of production A seeder with no env field always runs — that is the right default for reference data. A seeder that declares one runs only in those environments: The environment comes from --env, else the runner's own env option, else NODEENV. If none of them resolves, an env-scoped seeder is skipped rather than run — the failure mode that matters is dev fixtures leaking into production, not reference data arriving late. Order, and what a seeder should assume Files run in filename order, which is why the CLI timestamps them. A seeder that depends on another's rows must sort after it — but a seeder that needs a particular id is usually better off looking it up: Two more things worth deciding deliberately: Seeders are not migrations. They assume the tables already exist. Run migration:run first — the CLI does not chain them for you. down should be exact. bulkDelete('roles', {}) empties the table, including rows somebody else added. Delete what the seeder inserted. Events SeederRunner is an EventEmitter, which is enough for progress output or timing in CI: Options Option | Does | --- | --- | seedersPath | Where the files are. Defaults to the path passed to runSeeders(). | seedsTableName | Tracking table. Defaults to PrormData. | pattern | Which files count as seeders. | env | Environment for scoping, falling back to NODEENV. | runSeeders(path?, options?) additionally takes only (one seeder by name), env (wins over the runner's) and force (re-run an executed one; needs only). Related reading Migrations — the other half of the same machinery QueryInterface — what up/down are handed Bulk operations — inserting many rows efficiently CLI — the db:seed commands in full