Factory Laravel Package

Product Decisions This Supports

• ORM selection for a Laravel-based product: this package is the concrete cost-of-adoption evidence for choosing Analogue (Data Mapper) over Eloquent (Active Record). If factories work out of the box, we keep test-authoring velocity; if they don't, that's engineering time added to the Analogue line item in the build-vs-buy comparison.
• Build vs. buy vs. fork for test tooling: it's a thin adapter between Laravel's factory() builder and Analogue's EntityManager. The realistic decision is fork-and-own or write in-house, not depend on it — 1 star, 0 dependents, no release since Feb 2018 means no security response, no Laravel 8+ class-based factory support, no PHP 8 support.
• Architecture roadmap: if the product needs a persistence-ignorant domain (hexagonal / DDD boundaries, multiple datastores, or a migration off Laravel's ORM), this package tells you what "day two" tooling cost looks like for any non-Eloquent ORM in the Laravel ecosystem. Eloquent is the path of least resistance; every alternative needs glue for factories, seeders, and test fixtures.
• Delivery-velocity decisions: fixture generation underpins integration tests and demo/seed data. Any ORM choice that breaks factory() silently taxes every sprint after the first one.
• Concrete use cases it enables (only if Analogue is already in play): entity fixtures for integration tests, deterministic demo data for sales/staging environments, and seeding a legacy Analogue domain model running inside a Laravel app.
• Migration triage: useful as a reference implementation when porting a legacy Analogue codebase into a modern Laravel app, or when deciding whether to keep Analogue vs. rewrite onto Eloquent/Doctrine.

When to Consider This Package

Consider it if:

• You are already committed to analogue/orm inside a Laravel application and need factory() support for tests or seeders — and you accept that adopting it means forking it.
• You are running a formal ORM evaluation and want to measure real integration cost, not vendor claims.
• Your Laravel version is 5.x-era and your PHP is ≤7.x, matching the package's 2018 release window.
• You need a working reference for how to bridge a third-party EntityManager into Laravel's factory Builder contract — the pattern is reusable even if the code isn't.

Look elsewhere if:

• Greenfield Laravel product → use Eloquent; this package solves a problem you don't have.
• You need class-based factories (Laravel 8+, 2020) or PHP 8 — the package predates both. Its closure-based factory API will not match modern Factory classes.
• You require a maintained dependency with an SLA, security patching, or a responsive maintainer. One star, zero dependents, and eight years without a release is a hard no for production-critical test infrastructure.
• Doctrine or Cycle ORM is the actual candidate — look at doctrine/data-fixtures, zenstruck/foundry (Symfony), or plain PHP fixture builders plus database transactions instead.
• Your test suite is the release gate for a commercial product: a single-maintainer, single-star package in the test path is a bus-factor risk.

Reading the scores honestly: the 0.135 quality/maintainability score and near-zero adoption confirm this is archival code, not a dependency. The high opportunity score reflects scarcity — almost nothing else bridges Analogue to Laravel factories — not viability. Scarcity in an abandoned niche is a warning, not a market.

How to Pitch It (Stakeholders)

For executives (one paragraph): Analogue Factory is a small, free integration shim that lets Laravel's test-data factories work with the Analogue ORM instead of Laravel's default database layer. It is not a product we should adopt: one GitHub star, no downstream users, no release since early 2018, and it predates modern Laravel. Its value to us is as evidence, not as a dependency — it lets us price the "hidden" cost of stepping outside Laravel's default ORM, which is roughly one engineer-sprint of fixture and test tooling we would have to own and maintain forever. Recommendation: stay on Eloquent unless a domain-complexity requirement genuinely forces a data-mapper ORM; if it does, budget that sprint explicitly and build the adapter in-house rather than inheriting abandoned code.

For engineering:

• Treat it as a reference implementation, not a dependency. Read it to understand the seam between Laravel's factory Builder and Analogue's EntityManager; then write a ~hundred-line adapter you control.
• Adopting as-is means: forking, adding PHP 8 compatibility, and either backporting to Laravel 8+ class-based factories or pinning the whole test suite to legacy factory syntax. That fork becomes ours to own with no upstream to merge from.
• Isolate the risk: keep the adapter behind a thin internal interface so swapping Analogue for Eloquent or Doctrine later doesn't touch test files.
• Decision gate: if we can't justify owning that adapter on the roadmap, we can't justify Analogue — the ORM choice and the tooling cost are the same decision.