Doctrine Fictures Extra Bundle Laravel Package

Getting Started

First, a candid note: this is a Symfony bundle built on Doctrine, not a Laravel package. A Laravel developer reaching for it is almost certainly working inside a Symfony/Doctrine codebase (or a mixed stack) rather than in Eloquent-land. If you're staying in Laravel, this package does not apply — you'd be looking at RefreshDatabase, migrate:fresh --seed, or doctrine/dbal-adjacent tooling instead.

The package's whole purpose is to wrap four Doctrine console commands into one:

• doctrine:schema:validate
• doctrine:schema:drop
• doctrine:schema:create
• doctrine:fixtures:load

…so you can reset a database and refill it with fixtures in a single invocation.

Minimal steps:

1. Install with Composer, alongside the Doctrine and fixtures bundles it depends on:

   composer require --dev yeroon/doctrine-fixtures-extra-bundle
   

   You also need doctrine/doctrine-bundle and doctrine/doctrine-fixtures-bundle present — this bundle layers on top of them.

2. Register the bundle. On Symfony 4+ Flex projects this is usually automatic via auto-registration in config/bundles.php. On older Symfony versions add it to AppKernel::registerBundles():

   if (in_array($this->getEnvironment(), ['dev', 'test'])) {
       $bundles[] = new Yeroon\DoctrineFixturesExtraBundle\YeroonDoctrineFixturesExtraBundle();
   }
   

3. Look at the command list first. Run bin/console list (or app/console list) and grep for the bundled command name — this is your source of truth for options and arguments, since the README is thin and the package has essentially no users to crowd-source answers from.

4. First use case. The intended workflow is a fast local reset: after changing an entity mapping, run the command to validate the schema, drop it, recreate it, and reload fixtures — no manual schema:drop + schema:create + fixtures:load dance. Treat it as a developer-convenience command for a dev/test database, not something you'd wire into production.

Implementation Patterns

Local "nuke and pave" loop. The most common pattern is aliasing the command into your own Symfony Console\Command or a Makefile/Composer script, so a whole reset is one keystroke. Keep the wrapper thin so you can still pass through flags.

CI/dev environment seeding. Because it validates the schema before dropping, it doubles as a lightweight smoke test: a broken mapping fails fast at the schema:validate step rather than after a destructive drop. That's the one genuinely useful property worth leaning on — sequence validation before destructive operations.

Fixtures as first-class data. Pair it with DoctrineFixturesBundle fixture classes and (optionally) nelmio/alice for YAML fixtures. Load order and fixture dependencies are managed by the fixture loader, not this bundle, so keep fixture classes small and idempotent — the command reloads, it doesn't migrate.

Environment gating. Wrap registration in a dev/test check (as in the example above). This command drops tables; registering it globally is asking for an accident. If you need it further afield, gate it behind an explicit confirmation flag or a custom guard.

Composing with your own commands. Rather than calling the bundled command from shell scripts, prefer Symfony's Application::find() + run() inside a custom command if you need pre/post hooks (e.g., disable foreign key checks, flush caches, seed object storage). This keeps logic in PHP and testable.

Gotchas and Tips

• This is not a Laravel package. No service provider, no php artisan command, no facade. Any Laravel-side integration would require writing your own wrapper around the equivalent Doctrine migrations/schema tooling. Don't assume composer require will "just work" in a Laravel app.
• Zero stars, zero dependents, likely unmaintained. Treat the README and the actual command source as the authoritative docs, and read the command class before trusting it. Pin the version and be prepared to fork — the surface area is small enough that forking is trivial.
• Destructive by design. The command's job is to drop the schema. It must never run against a shared or production database. Add environment guards, and consider a confirmation prompt in the wrapper.
• Dependency drift. Because it wraps doctrine/doctrine-bundle and doctrine/doctrine-fixtures-bundle, version constraints can silently conflict with modern Doctrine (DBAL 3/4, ORM 2/3). Check the bundle's composer.json constraints before installing; on newer Symfony/Doctrine you may need to allow-flex or patch constraints.
• schema:drop pitfalls. On MySQL, dropping tables with foreign keys/--full-database behavior differs from Postgres; SQLite behaves differently again. If the wrapped command hard-codes a --force or --full-database flag, verify it matches your platform.
• Validate is not migrations. schema:validate compares mapping vs. DB, but it does not run your Doctrine migrations. If your project relies on doctrine/migrations, this command will bypass migration history and leave the migration_versions table out of sync — recreate it or re-run migrations afterward.
• Debugging tip. Run the four underlying commands individually when the combined command fails; the bundled command obscures which step broke. -vvv on the console command usually reveals the chained call.
• Extension points. Since it's a thin wrapper, the realistic extension is the fixture classes themselves and, if needed, subclassing/replacing the command to add hooks. There's almost no configuration surface to speak of beyond registration.
• Bottom line for a Laravel dev: unless you're explicitly maintaining a Symfony/Doctrine app, this offers no value. Even there, it's a convenience wrapper you could reproduce in ~30 lines of a custom console command — often the safer path than depending on an unmaintained, zero-star bundle.