Zanui Fixtures Bundle Laravel Package

Getting Started

Before writing any code, understand what you are actually installing: zanui/zanui-fixtures-bundle is a Symfony bundle, not a Laravel package. It targets the Symfony 2.x era (last release August 2014), predates PSR-4 being the default convention, and has effectively zero adoption (1 star, no dependents). There is no composer require-and-go path into a Laravel app.

Realistic first steps for a Laravel developer:

1. Read the source before trusting it. Clone the repo and inspect composer.json first — the require block tells you the Symfony/PHP version constraints, and the autoload block tells you whether it uses PSR-0 or PSR-4. Anything pinned to symfony/symfony: ~2.x will not resolve cleanly in a modern Laravel project without --ignore-platform-reqs, which is a red flag on its own.
2. Identify the bundle entry point. Symfony bundles expose a class extending Bundle (conventionally <Vendor><Name>Bundle). That class, plus any DependencyInjection/ and Resources/config/ directories, is where the real behavior lives. There is no Laravel service provider here, and registering the bundle's services in a Laravel container is not a supported operation.
3. Decide on your actual first use case. The only sensible framing is "I need repeatable seed data for local/staging environments." Laravel already solves that with database/seeders and Faker. The only reason to look at this bundle is if you are maintaining a legacy Symfony application and want fixture-loading conventions that match it — not to introduce it into Laravel.

Bottom line: treat this as reference material or a Symfony-legacy dependency, not a Laravel install. For a greenfield Laravel project, stop here and use php artisan make:seeder / db:seed.

Implementation Patterns

If you are working in a Symfony codebase that already depends on this bundle (or porting its ideas into Laravel), the patterns worth understanding are:

Fixture-as-PHP-class pattern. The standard convention (inherited from DoctrineFixturesBundle lineage) is one class per entity/table implementing an load()/run() method that constructs and persists objects. If you are porting this to Laravel, the mapping is straightforward:

• Symfony fixture class → Laravel Seeder subclass with a run() method.
• Doctrine EntityManager::persist()/flush() → Eloquent Model::create() or insert() for bulk work.
• Fixture ordering via bundle config → $this->call([UserSeeder::class, PostSeeder::class]) in DatabaseSeeder.

Environment guarding. Fixture bundles are almost always wired to run in dev/test only. In Laravel, replicate this with an explicit guard at the top of destructive seeders:

if (app()->environment('production')) {
    throw new RuntimeException('Refusing to seed production.');
}

Dependency ordering. Any fixtures bundle that handles relational data has to solve ordering. Look for an ordering mechanism (array config, priority, or explicit getDependencies()). The Laravel equivalent is explicit $this->call() sequencing, which is more predictable than relying on discovery/priority.

Idempotency. Well-written fixture loaders either truncate-then-load or upsert. When porting, prefer updateOrCreate() in Laravel so re-seeding is safe, rather than blindly inserting duplicates.

Composition with Faker. The 2014-era approach embeds Faker\Generator directly in fixture classes. In Laravel, inject it via the container or use fake() — don't hardcode new Faker\Generator() because the locale/config wiring won't match.

Gotchas and Tips

• It is not a Laravel package. No service provider, no facade, no config/ publish tag. Attempting composer require in a Laravel app will likely fail dependency resolution against modern Symfony components. Do not fight it with --ignore-platform-reqs.
• Unmaintained since 2014. That is ~10 years without a release. Assume it will never receive PHP 8.x, Symfony 6/7, or security fixes. Do not introduce it into any codebase you intend to keep.
• PSR-0 autoloading. Pre-2015 bundles frequently use PSR-0 (autoload: {psr-0: ...}), which Composer still supports but which no longer matches modern class-to-file layouts. If you copy classes into a Laravel app, re-map namespaces to App\... with PSR-4.
• composer.json is your source of truth. Because there is no documentation, the require, autoload, and extra blocks are the only reliable description of what the package expects. Check extra.branch-alias and the target-dir key (a PSR-0 artifact) — their presence confirms legacy packaging.
• Zero dependents means zero battle-testing. There is no Stack Overflow corpus, no issue history to learn from. Any bug you hit is yours to fix.
• Extension points are convention-based, not documented. In Symfony bundles the extension points are typically the bundle class (getContainerExtension()), DI compiler passes, and tag-based service collection. If the repo has none of these, there is nothing to extend — only to fork.
• Migration advice for Laravel teams: adopt the idea (structured, ordered, environment-guarded seed classes with Faker), not the code. Laravel's built-in seeders cover the same ground with first-class framework support. Reserve time for a straightforward port rather than an integration.
• Debugging tip if you must run it in a Symfony context: enable the bundle in the kernel, clear the container cache (bin/console cache:clear), and check that the bundle's Resources/config/services.yml actually loaded by dumping the container. Most failures with old bundles are silent service-not-registered errors.