Doctrine Fixtures Timing Bundle Laravel Package

Product Decisions This Supports

• Build vs. adopt (the primary decision here). This package is a Symfony bundle, not a Laravel package — there is no bundles.php, no kernel.event_listener tag, and no DoctrineFixturesBundle in a standard Laravel stack. So the real decision it informs is narrow: do we adopt it (only viable in a Symfony/Doctrine context) or do we read it as a reference and build a ~50–100 line Seeder/Command event listener in-house? For a Laravel-first product, the answer this package supports is build, don't depend.
• Test/CI runtime investment. The capability — per-fixture execution timing — converts "the suite feels slow" into a ranked list of culprits. That is the evidence needed to justify roadmap time on fixture refactoring, seeder strategy, or database reset approach. The package demonstrates the shape of that instrumentation even if we don't ship it.
• Developer-experience roadmap sequencing. Timing data at the fixture/seed layer is a cheap first step before committing to heavier tooling (Laravel Telescope, Blackfire, Tideways). This assessment supports treating instrumentation as a ladder, not a single purchase.
• Quality-gating policy. Per-item durations are the precondition for any CI threshold or regression check on seed/fixture duration. Decide now whether seed time is a tracked metric or just a local annoyance.
• Dependency governance. Zero stars, zero dependents, single author, one v1.0.0 release with no release notes body. That profile supports a standing policy: acceptable only as require-dev or as a code reference, never load-bearing, never production.
• Scoping hygiene. The most valuable decision this supports is classification. Recording "Symfony bundle; not installable in Laravel; pattern-source only" prevents a sprint being spent proving a known mismatch.

When to Consider This Package

Consider the package itself when:

• The codebase is Symfony + DoctrineFixturesBundle, fixtures are a meaningful share of test or local setup time, and the team wants targeted visibility without adopting a full APM/profiler.
• A Laravel shop runs Doctrine alongside Eloquent and uses Doctrine fixtures as the fixture runner — a rare configuration, and even then the event wiring will need a custom adapter.
• You want a low-cost reference implementation: a one-day spike reading the source is a legitimate way to steal a design before writing your own listener.

Look elsewhere (or reconsider the need) when:

• The stack is Laravel/Illuminate-based — use php artisan db:seed --verbose, a Seeder event listener, or Telescope instead. These carry no cross-framework integration tax.
• You need application-wide or production profiling (Symfony Profiler, Blackfire, Tideways, Laravel Telescope).
• Fixture/seed loading is not a measured bottleneck — adding a dependency to answer an unasked question is unjustified.
• You need maintained, supported dependencies. Single-author packages with a bare-bones 1.0.0 changelog are a maintenance question, not just a technical one.
• Fixture counts are large (hundreds): per-fixture output becomes noise; you want aggregated top-N and total wall time, which no small tool in this space provides.

Before committing, verify: PHP/Symfony support matrix from composer.json (not the tag alone); whether the listener is console-only or hooks Doctrine fixture-load events; the measurement mechanism (standalone microtime is portable to Laravel, a profiler tie-in is not); and issue/PR velocity as a maintenance signal.

How to Pitch It (Stakeholders)

For executives: The proposal is deliberately small. We are not asking to adopt a new dependency — this is a single-author Symfony package with no dependents and no meaningful release narrative, and it does not install into our Laravel stack. What we are asking for is a timeboxed one-day spike to read it as a reference implementation, followed by a build-vs-adopt call. Expected output is roughly 100 lines of in-house seeder timing, owned by us, with no vendor spend and no ongoing dependency risk. The value is faster developer feedback loops and a defensible answer to "why is CI slow," not a new piece of infrastructure.

For engineering: Treat this as a Symfony bundle and a design reference, not a Laravel package. Direct adoption requires a Symfony kernel plus DoctrineFixturesBundle; in Laravel the equivalent is a Seeder/Command event listener that captures microtime around each seeder and logs per-item durations. One-day spike to confirm the instrumentation is genuinely standalone microtime (portable) and not tied to Symfony's profiler or Doctrine fixture events (not portable), then decide: port ~100 lines and own it, or close the ticket and rely on --verbose/Telescope. If we do depend on it anywhere, pin aggressively, keep it in require-dev, and accept that a broken release should degrade one developer's local profiling and nothing more. Do not let this package gate a fixture-performance initiative.