Fixture Bundle Laravel Package

Getting Started

This is a Symfony2-era bundle, so everything assumes the old kernel/bundle registration model rather than Symfony Flex. Before committing to it, confirm the branch you need (composer show funddy/fixture-bundle --all) — Symfony2 support usually lives on a 1.x/2.x line with tight PHP constraints.

1. Install into the existing Symfony2 app:

   composer require "funddy/fixture-bundle:~1.0"
   

   If Composer resolves a conflict against your Symfony version, that is the first signal the package has drifted from your stack — check the composer.json require block in the vendor directory before fighting it.

2. Enable the bundle in app/AppKernel.php:

   $bundles = array(
       // ...
       new Funddy\FixtureBundle\FunddyFixtureBundle(),
   );
   

3. Look here first, in this order:

   • vendor/funddy/fixture-bundle/Resources/config/ — the service definitions tell you exactly what the bundle wires and what you can override.
   • vendor/funddy/fixture-bundle/DependencyInjection/ — the extension class shows every config key under the funddy_fixture: root (loader type, directories, defaults).
   • vendor/funddy/fixture-bundle/Command/ — any console commands (app/console list | grep fixture) are the fastest way into the intended workflow.

4. First use case: register a fixture file (or fixture class, depending on which loader the bundle ships), then run the bundle's console command with app/console against your dev database. Confirm the row counts changed before wiring anything into test setup — this validates the config root and loader path in one step.

Because the package has effectively no ecosystem (0 dependents, single-digit stars), treat the repo's README and its own test suite as the primary docs, not blog posts.

Implementation Patterns

Configuration-driven fixtures. Most bundles of this vintage expose a funddy_fixture: config block pointing at a directory of fixture files and a loader (YAML/JSON/PHP). The day-to-day pattern is: put fixtures in app/Resources/fixtures/, point the config at that directory, and run the load command per environment. Keep dev and test fixture directories separate so test suite runs aren't polluted by demo data.

Fixture classes with a load hook. If the bundle exposes an abstract fixture class, extend it and implement the populate method; register the class via the bundle's service tag or config list. Use the constructor (or a setContainer-style hook) to inject the EntityManager rather than reaching for the container inside load().

Ordering and dependencies. Fixtures almost always have FK ordering problems (users before posts, etc.). Look for a priority, order, or depends key in the config extension — if it exists, use it explicitly rather than relying on file sort order. If it does not exist, name files with numeric prefixes (01-users.yml, 02-posts.yml) and verify the loader respects directory iteration order.

Integration with Doctrine. If the bundle wraps Doctrine DataFixtures, you can usually register both and let Doctrine handle execution while the bundle handles file discovery/parsing. Check whether the bundle's command is a thin wrapper (doctrine:fixtures:load with an appended path) — if so, prefer the Doctrine command directly and use this bundle only for its parser.

Functional test usage. The highest-leverage pattern for a small app is loading a minimal fixture set in setUp() of an integration test via the bundle's programmatic loader service (grab it from the test container, call the load method). Keep an isolated test fixture dir with only what each test class needs — the whole-app fixture load is too slow and too coupled.

Idempotency. If the loader supports truncate-before-load, prefer that over appending, otherwise re-running in dev after a schema change produces duplicate rows and confusing FK errors.

Gotchas and Tips

• Maintenance reality. This is a 3-star, no-dependents Symfony2 package. Symfony2 is EOL. Before building on it, check the repo's last commit date and open issues. If you are starting a new project, doctrine/doctrine-fixtures-bundle (or nelmio/alice for richer fixtures) is the safe choice; use this bundle only if you're maintaining an existing app that already depends on it.
• PHP/Composer constraints. Expect php: >=5.3 style constraints and old Symfony ranges. On modern Composer this can surface as "requirements could not be resolved" even when the code would run — pin Symfony 2.x in your root composer.json or use --ignore-platform-reqs only as a last resort.
• Config root name. The DI alias is not always the bundle name lowercased with underscores. Grep the extension class (getAlias()) before guessing in config.yml.
• Silent empty loads. If the command exits 0 but nothing is inserted, the loader directory path is almost always wrong (relative to project root vs. bundle root). Add -v/-vv to the command and check the resolved directory.
• Debugging. Use app/console container:debug | grep fixture to confirm the loader service is registered and which class backs it. Then --env=dev with the profiler on to see if the loader is being invoked at all vs. failing silently on an empty glob.
• Extension points. The bundle's service definitions are the intended override surface — override a service id in config.yml with your own implementing class if you need a custom parser or loader, rather than forking the vendor directory.
• Don't mix fixture strategies. If part of your fixtures are Doctrine DataFixtures and part are this bundle's format, pick one entry point for CI/test setup, otherwise ordering and truncation behavior diverge between dev and test and produce "works on my machine" failures.