home / skills / noartem / skills / laravel-migrations-and-factories

laravel-migrations-and-factories skill

safe

/skills/laravel-migrations-and-factories

This skill enforces safe Laravel migrations and factories, guiding when to modify or add migrations, and pairing models with seeds for realistic, tested

npx playbooks add skill noartem/skills --skill laravel-migrations-and-factories

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.1 KB

---
name: laravel-migrations-and-factories
description: Safe database change patterns; when to modify vs add migrations; always pair models with migrations and factories; seeding guidance
---

# Migrations and Factories

Keep schema changes safe, testable, and reversible.

## Commands

```
php artisan make:model Post -mfc

# Run/rollback
php artisan migrate
php artisan migrate:rollback --step=1

# Fresh DB (dangerous; dev only)
php artisan migrate:fresh --seed
```

## Rules

- Pair each new model with a migration and a factory
- If a migration was merged to `main`, never edit it—add a new one
- On feature branches, you may amend migrations created on that branch (if not merged)
- Seed realistic but minimal datasets in seeder classes; keep huge datasets external

## Factories

- Prefer state modifiers (e.g., `->state([...])`) over boolean flags
- Use relationships (e.g., `belongsTo`) in factories to build realistic graphs
- Keep factories fast; move expensive setup to seeds where possible

## Testing

- Use factories in tests; avoid manual inserts
- For integration tests touching DB, use transactions or `RefreshDatabase`

Overview

This skill teaches safe, testable Laravel database change patterns focused on migrations, models, factories, and seeding. It emphasizes rules for when to modify versus add migrations, pairing models with migrations and factories, and practical guidance for seeding and testing. The goal is reliable schema evolution and fast, maintainable test data.

How this skill works

The skill inspects common workflows and enforces practices: always create a migration and factory when adding a model, avoid editing migrations already merged to main, and prefer adding new migrations for schema fixes. It recommends using factory states and relationships to produce realistic test data, and separates expensive dataset creation into seeders. It also outlines safe commands and test patterns like RefreshDatabase and transactional tests.

When to use it

Creating a new Eloquent model and its database schema
Fixing or extending an existing schema already deployed or merged
Writing tests that require realistic but fast database records
Seeding development or CI environments with minimal realistic data
Refactoring factories to use states and relationships for clarity

Best practices

Always pair a new model with a migration and a factory using php artisan make:model -mfc
Never edit a migration after it has been merged to main; create a new migration to alter schema
On feature branches you can amend migrations you introduced before they are merged
Use factory state modifiers and relationship builders instead of boolean flags
Keep factories fast; move heavy or large dataset generation to seeders
Use RefreshDatabase or transactional tests for integration tests touching the DB

Example use cases

Add a Post model with migration and factory in one command, then seed minimal sample posts for local dev
Introduce a new column in production: create a new migration that alters the table instead of editing an old migration
Write feature tests that build user-account relationships via factories with belongsTo and state methods
Seed CI with small realistic datasets and keep large anonymized exports outside seeders
Refactor an existing factory to remove boolean flags and add expressive states for different test scenarios

FAQ

Can I edit a migration I created on my feature branch?

Yes—if the migration hasn't been merged to main yet. Once it's merged, create a new migration instead of editing history.

Should factories create related records or rely on seeders?

Use factories to build related records for tests via relationships and states. Reserve expensive or bulk dataset creation for seeders.