Fixtures Mapper Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for seed/fixture tooling. This package is a reference pattern, not an adoption candidate: archived, 21 stars, 0 dependents, Symfony2-era. The decision it informs is "copy the idea, don't take the dependency." Realistic cost to reproduce the useful part (declarative file → entity mapping with per-type mappers) is 1–3 days for a spike and 1–2 weeks to productionize in Laravel — cheaper than owning an abandoned dependency.
• Choosing who authors test/demo data. The genuine product win here is workflow: business analysts, QA, or clients hand over CSV/YAML instead of filing tickets for developer-written PHP fixtures. That's a decision about data ownership and turnaround time, and it's independent of this package. Specify it as a requirement and deliver it with supported tooling.
• Framework-fit gating (the decisive one). This is a Symfony bundle — kernel registration, DI extension, Doctrine Data Fixtures. It does not install or run in Laravel; there is no port and no artisan path. For a Laravel roadmap the correct answer is native db:seed, model factories, fakerphp/faker, and a CSV-import library (e.g., league/csv or flynsarmy/csv-seeder). Same problem, different ecosystem, different build-vs-buy answer.
• Legacy Symfony upgrade planning. Where it's already in a Symfony 2.x app, it becomes a scheduled migration item: keep during a 2→3/4 step, replace before 5/6/7. Surfacing it now prevents it blocking a framework upgrade mid-flight.
• Reference-data and demo seeding scope. Country/currency lists, catalogs, pricing tables, permission matrices, client-supplied sample datasets — spreadsheet-shaped data suited to demo/staging and smoke tests. Explicitly not the unit-test layer, where file-based data drifts and factories are the better tool.
• Test-data strategy split. File-based seeding is convenient but slow and hard to isolate transactionally. Committing to it means committing to a second, code-level layer for deterministic tests — a scoping and effort decision worth making up front.

When to Consider This Package

Consider (narrowly):

• You maintain an existing Symfony 2.x application already using the bundle and need fixture loading from CSV/YAML through a staged upgrade. Keep it temporarily; do not extend it.
• The requirement is specifically "stakeholders supply fixture data as CSV/YAML" and delivery happens in a legacy Symfony context.
• Internal, low-blast-radius tooling where an unmaintained dependency is tolerable and MIT allows vendoring or forking under your own ownership.
• As a reading reference: clone it into a throwaway Symfony skeleton to study the mapper/coercion/relation-ordering approach before writing a Laravel-native importer.

Look elsewhere:

• Any Laravel codebase. Not compatible, no port. Use seeders, factories, faker, and a CSV library.
• Greenfield or actively maintained Symfony (5.x/6.x/7.x). Archived, pre-PHP 8, no current Doctrine guarantees. Use DoctrineFixturesBundle for loader mechanics plus a maintained YAML/Alice bundle if file-authored fixtures are needed.
• You need support, security patching, or to pass a supply-chain review. Archived + zero dependents + no CVE response is disqualifying for anything customer-facing or long-lived; expect third-party risk assessment to reject it.
• High-volume or performance-sensitive seeding. File parsing plus a mapping layer is slower than factories; row-by-row inserts won't scale past tens of thousands of records without chunking and upsert.
• Deterministic unit-test fixtures. File data drifts; use builders/factories.
• Production data import. This is a batch dev/CI tool. If the requirement is a production pipeline, reject the approach early rather than scaling it.

How to Pitch It (Stakeholders)

To executives: A small, archived Symfony 2 library for loading demo and test data from CSV or YAML files through custom mapper classes. It addresses a real but minor problem and is not a strategic dependency — 21 stars, zero downstream projects, no maintenance, no security patching. Recommendation: do not add it to any new product, and note that it is not Laravel-compatible, so it cannot serve our primary stack. Where it already exists in a legacy Symfony application, treat it as a scheduled replacement item during the framework upgrade rather than a component to build on. The capability worth keeping — letting analysts supply test data as spreadsheets — is achievable with current, supported tooling at modest engineering cost. MIT license means no procurement friction either way.

To engineering: Do not introduce this as a dependency. It's a Symfony2 bundle, unmaintained, and unversioned against modern PHP/Symfony/Doctrine. Three viable paths, in order of preference: (1) evaluate maintained alternatives first — one day, and it may end the discussion (flynsarmy/csv-seeder, orangehill/iseed, or plain seeders); (2) write a thin Laravel-native importer — an artisan fixtures:load command plus a small package, reading CSV/YAML, resolving Eloquent models, mapping columns to attributes with an explicit cast registry — roughly 1–3 days for one entity spike, 1–2 weeks productionized; (3) if reference behavior is genuinely needed, vendor the framework-light mapper logic under MIT and treat it as ours to maintain, discarding the bundle and DI glue. Whatever the path: strict column validation with fail-fast on unknown headers, explicit topological ordering for relations, chunked inserts, and streaming CSV rather than whole-document YAML for large files. Keep file-authored data for demo/integration seeding; keep factories for unit tests.

To product/QA: The workflow win — handing over test data as CSV or YAML instead of filing tickets for developer-written fixtures — is real and should be captured as a requirement, not as a library choice. Expect us to deliver it on supported tooling, with validation errors surfaced clearly (bad headers, ambiguous dates, encoding problems) so non-developers can self-correct without engineering time. Budget modest engineering effort, no licensing cost, and plan for this being a dev/staging/demo capability rather than anything touching production data.