Fixtures Plugin Laravel Package

Getting Started

Reality check first: this is not a Laravel package. monofony/fixtures-plugin is a Symfony bundle for Monofony (a Sylius-derived e-commerce framework built on Symfony, Doctrine ORM, and Alice/Nelmio fixtures). There is no service provider, no Eloquent, no Artisan seeder, and no factory support. If your app is Laravel, stop here — replicate the intent with db:seed, model factories, and orangehill/iseed rather than attempting to bridge ecosystems. Only proceed if you're working inside a Monofony/Symfony application.

Assuming a Monofony app:

1. Read before installing. Check composer.json for PHP/Symfony/Monofony/Sylius constraints, glance at the CHANGELOG and recent commits (1 star, 0 dependents means upstream responsiveness is effectively zero).
2. Install:

   composer require monofony/fixtures-plugin
   

3. Register the bundle in config/bundles.php (Flex may do this automatically):

   Monofony\Bundle\FixturesPlugin\MonofonyFixturesPlugin::class => ['all' => true],
   

4. Discover the command — do not assume the name:

   bin/console list monofony
   bin/console list sylius
   

   Confirm whether it's monofony:fixtures:load, sylius:fixtures:load, or something plugin-specific before writing scripts.
5. Locate fixture definitions. Look in your app's fixture directory (config/fixtures/ or fixtures/) and inspect src/ for Fixture\, Loader\, DependencyInjection\, and Command\ namespaces to understand what's wired.

First use case: seed a fresh dev database so you can log in as an admin/customer on a brand-new Monofony app without hand-crafting users — that's the 80% value of the plugin.

Implementation Patterns

Suite-based loading. Organize fixtures into named suites (default, dev, demo, test) and load one at a time:

bin/console monofony:fixtures:load default
bin/console monofony:fixtures:load test --no-interaction

Add your own fixtures. Alice YAML conventions apply; reference existing fixtures via @reference_name:

# config/fixtures/user.yaml
App\Entity\Customer:
    customer_dev:
        email: '[email protected]'
        firstName: 'Dev'
        enabled: true

Override shipped fixtures without forking. Use Symfony bundle resource overrides or decorate the fixture suite interface. Idiomatic Sylius/Monofony approach: replace the fixture file via Resources/config/ override path, so core upgrades don't clobber your data.

CI/test database seeding. Wire the command into your test bootstrap:

bin/console doctrine:database:create --if-not-exists
bin/console doctrine:migrations:migrate --no-interaction
bin/console monofony:fixtures:load test --no-interaction

Programmatic loading. Inject the loader service into a custom command or test base class:

public function __construct(private FixtureLoader $loader) {}

$loader->load('test'); // verify the exact signature in src/

Compose per-environment suites. Keep default lean (roles, admin user), dev/demo richer (products, orders), test minimal for speed — this avoids polluting assertions while keeping pipelines fast.

Pair with a reset step. Fixture loading typically appends; design fixtures with deterministic references or precede with doctrine:database:drop --force on local to keep reruns idempotent.

Gotchas and Tips

• Ecosystem mismatch is total. Nothing here maps to Laravel. If your team is Laravel-only, budget for learning Symfony container, Doctrine ORM, and Alice — a cost disproportionate to the value of a 1-star fixture plugin.
• Command name drift. Different Monofony/Sylius versions expose sylius:fixtures:load vs monofony:fixtures:load vs plugin-specific. Always run bin/console list first; don't copy command names between projects.
• Load order matters. Alice @reference_name resolves only when the referenced fixture is defined earlier in the suite. "Reference not found" almost always means ordering, not entity mapping.
• Doctrine coupling. The plugin assumes Doctrine ORM entities with Monofony core mappings. Custom entities or non-Doctrine persistence fail silently at flush() — run with -vvv and inspect the entity manager state.
• Schema before fixtures. doctrine:schema:validate and a passing migration must come first; fixture load errors often mask "table doesn't exist."
• Cache after config changes. Editing bundle config or fixture paths requires bin/console cache:clear (and cache:warmup for prod-like envs).
• Maintenance risk is the dominant concern. 1 star, 0 dependents, near-zero upstream responsiveness. Pin the version explicitly in composer.json (or vendor a fork at a pinned SHA) and review diffs on every Monofony upgrade — fixture schemas frequently lag entity migrations.
• Never in production. Guard the command behind an APP_ENV assertion (dev|test). Shipping fixture credentials into prod is the classic footgun.
• Extension points. Decorate the loader/suite interfaces rather than monkey-patching vendor files, and register custom fixtures as tagged services (verify the tag name in DependencyInjection/) instead of hard-coding them.
• Debugging recipe. -vvv, enable any nelmio/alice debug option, check var/log/dev.log, and add a smoke test that loads fixtures into a fresh schema — that's the single most valuable safeguard against silent schema drift surfacing only in CI.