- Is graviton/mongodb-fixtures-bundle a Laravel package?
- No. It is a Symfony bundle built around Doctrine MongoDB ODM and Symfony's bundle registration and DI container, and it is explicitly positioned as a drop-in replacement for liip/test-fixtures-bundle. Laravel has no native seam for Symfony bundle wiring, so adapting it would mean maintaining a fork. For Laravel, use doctrine/mongodb-odm with doctrine/data-fixtures plus a thin Artisan command or test trait instead.
- How do I install graviton/mongodb-fixtures-bundle?
- Install it with Composer and register the bundle in your Symfony application's config/bundles.php. It assumes Doctrine MongoDB ODM, the MongoDB PHP extension, and Liip-compatible fixture interfaces are already provided by the host application. Confirm the package's Composer constraints match your PHP, Symfony, ODM, and ext-mongodb versions before relying on it.
- How does it compare to liip/test-fixtures-bundle?
- It is described as a drop-in replacement for liip/test-fixtures-bundle that is dependency free and focuses only on MongoDB ODM fixtures. That narrower scope can reduce transitive dependencies, but you must verify exactly which Liip behaviors it reimplements, such as fixture discovery, purge versus append semantics, and ordering. Run both loaders against a representative suite and diff collection contents before removing Liip.
- Which Symfony, PHP, and Doctrine MongoDB ODM versions are supported?
- The available metadata does not clearly prove a support matrix, so treat version compatibility as unverified until you inspect the composer.json constraints and any CI configuration. Confirm your target PHP runtime, Symfony major version, Doctrine MongoDB ODM major version, and ext-mongodb driver version are all permitted together. Also verify the MongoDB server version used in CI matches what developers run locally.
- How do I load MongoDB fixtures in a Laravel application?
- Skip this bundle for Laravel. Use doctrine/mongodb-odm with doctrine/data-fixtures and wrap fixture loading in a small Artisan command or a test trait, which keeps the dependency set inside packages you already own. That is roughly the same amount of code as adapting a Symfony bundle, without converting a drop-in replacement into an internal fork.
- Can I use this bundle to seed development or production databases?
- The blurb mentions test and development database seeding, so treat it as test/dev-oriented rather than a production data tool. If you register it in a Symfony kernel, make sure production configuration cannot load it and that it never points at production collections. Use separate database names or environments and verify the purge behavior before running it anywhere outside tests.
- Does it support fixture ordering and dependency resolution?
- The package overview says it supports fixture ordering and dependency resolution so collections stay consistent across environments. If you are migrating from Liip, verify that the ordering rules and dependency semantics match what your existing fixture classes expect. Test with fixtures that depend on documents created by other fixtures, not just independent collections.
- How do I migrate from liip/test-fixtures-bundle to this bundle?
- Swap the bundle registration, keep your fixture classes in place, and confirm the MongoDB-specific loading path produces identical database state for a representative test suite. Run both loaders in parallel for one CI cycle, loading fixtures via Liip in one job and via this bundle in another, then diff collection contents. Remove the Liip path only after parity holds across ordering, purge, and append scenarios.
- Does it handle parallel test execution in CI?
- Parallel test support is not stated in the available information, so assume it needs verification for your setup. Check whether it isolates fixtures per worker through separate databases or collections, or whether concurrent runs will collide. If isolation is missing, add per-worker database naming in your test harness before adopting it broadly.
- Is graviton/mongodb-fixtures-bundle maintained and safe to depend on?
- The project shows no visible adoption, such as stars or dependents, which means there is no community to surface regressions and no obvious security response path. Being dependency free is a legitimate design stance and reduces transitive supply-chain exposure, but you become the only consumer testing upgrades. Before committing, decide who owns an internal fork if upstream goes quiet and whether that cost is acceptable for a test-only fixture loader.