Fixtures Bundle Laravel Package

Product Decisions This Supports

• Test/demo data strategy. The bundle's premise — load Doctrine fixtures per environment — maps directly to a recurring product question: how do we get realistic data into dev, CI, and demo/staging environments without polluting production or hand-crafting SQL. This is a decision about developer velocity and onboarding, not end-user features.
• Build vs. buy (and buy vs. steal). The core capability is a thin layer on top of doctrine/doctrine-fixtures-bundle: pick a fixture set based on %kernel.environment%. That is roughly a service definition plus a tagged fixture loader. The realistic options are: adopt this bundle, pin it, or reproduce the behavior in ~20–50 lines of app config.
• Roadmap input for platform tooling. If fixture-per-environment keeps surfacing in retros ("QA data is stale," "demo env looks empty," "CI seeds are inconsistent"), it justifies a small platform investment. This package is a useful reference implementation for scoping that work, even if we don't ship it.
• Dependency risk register. With 3 stars and 0 dependents, this is effectively an unmaintained, single-author bundle. Adopting it creates a long-tail maintenance obligation (Symfony/PHP version bumps, Doctrine ORM API changes) for a capability we could own trivially. That's a "no" on the supply-chain axis even if the feature is appealing.
• Use cases it actually unlocks: environment-specific seed sets (minimal fixtures in test, rich fixtures in dev), faster CI (no full seed in unit-test runs), and safer demo resets.

When to Consider This Package

Adopt-adjacent criteria (i.e., evaluate it):

• You are on a legacy Symfony 2.x/3.x application already using doctrine/doctrine-fixtures-bundle and you want env-conditional loading without writing custom code.
• Your team has no appetite for owning even a small internal bundle, and the fixture logic is genuinely stable (no expected schema churn).
• You have a dependency vetting exception process that permits low-popularity, low-risk dev-only dependencies — and you can confirm the bundle is dev/require-dev only, never shipped to production.

Look elsewhere (or build in-house) when:

• You are on Symfony 4+ / modern PHP (8.x). Use the Flex recipe, doctrine-fixtures-bundle's native fixture groups, and framework-native env handling instead. You almost certainly don't need a third-party bundle for this.
• Maintenance signal matters. 3 stars, 0 dependents, and a low opportunity score mean no community backstop: no one else will find and fix the breakage you hit. Every future Symfony major is your problem.
• You need more than env-switching: deterministic/faker-seeded data, truncation and referential-integrity ordering, per-tenant seeding, anonymized production snapshots. Those are different problems; this bundle solves the narrowest one.
• Your security/compliance posture requires provenance, SBOM coverage, and active maintainers for anything in the dependency graph.

Bottom line: treat this as prior art, not a purchase. Read the source, lift the pattern, and write it yourself if the need is real.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source add-on that lets us load different seed data depending on environment — lightweight fixtures for testing, richer data for demos and staging. The capability is genuinely useful for onboarding speed and demo quality, but the package itself is a single-maintainer project with negligible adoption (3 stars, zero dependent projects) and no maintenance guarantee. Recommendation: do not add it as a dependency. The same outcome is achievable with a small amount of configuration we already control, at lower long-term risk and near-zero cost. Net: keep the idea, drop the dependency.

For engineering (the ask): Confirm whether env-scoped fixtures are an actual pain point today. If yes, prototype the behavior in-repo using Doctrine fixture groups plus environment gating — scoped to a day of work, fully owned by us, no new third-party surface. If the answer is "not really a pain point," close it out and note it as a non-priority. In either case, this bundle stays out of composer.json; we may cite it as a design reference.

Risk framing if pushed to adopt anyway: dev-only dependency, pinned version, no production exposure — but we should record an explicit owner and a removal plan for the next Symfony upgrade, because that upgrade is where the cost will land.