Realdom Laravel Package

Product Decisions This Supports

• Verdict: do not adopt for new work. Hoa\Realdom is an archived (2017), 7-star, zero-dependent package. The only product decision this reliably informs is a negative one — it belongs on the dependency blocklist, not the roadmap.
• Build vs. buy → buy (elsewhere). The capability class — randomized/realistic test-data generation for PHP test suites — is a solved commodity. The decision this package supports is which vendor to standardize on: fakerphp/faker wrapped in Laravel model factories and seeders, not a bespoke or orphaned generator.
• Test-data strategy for feature work. If a team is prototyping fixtures, demo data, or property-style randomized testing, this is a reference point for what the capability looks like, not an implementation choice. The product outcome (fast, realistic fixtures that make CI deterministic) is worth funding; this library is not the vehicle.
• Tech-debt and dependency-governance prioritization. If hoa/realdom appears in a composer.lock (as a transitive dependency of the wider Hoa suite), it converts into a roadmap line item: an unscheduled modernization risk on the PHP 8 / Laravel 9–11 upgrade path, since the package predates and does not support that runtime.
• Platform/framework currency decisions. An archived dependency with no PHP 8 support is a forcing function in any "can we upgrade Laravel?" conversation — it becomes a blocker to schedule, size, and remove rather than a feature to extend.
• Signal for intake triage. The low composite score (0.3225) and low relative opportunity (18.82) are exactly the outputs your package-evaluation pipeline should produce for "abandoned but harmless." Use it as a calibration case: the pipeline correctly ranked it near the floor, so trust it to rank the next hundred candidates too.

When to Consider This Package

• Genuinely narrow adoption criteria: you are maintaining a frozen PHP 5.5–7.x codebase, the dependency is already pinned and working, there is no budget to touch that code path this cycle, and ripping it out carries more regression risk than leaving it. In that case, contain it — pin the version, vendor the source, and open a ticket with a removal date.
• Academic or archival reproduction: you are recreating a Hoa\Test / property-based testing setup from that era and need fidelity to the original stack. This is a research use case, not a product one.
• Air-gapped or no-Composer environments where pulling a maintained modern library is operationally impossible. Rare, and usually solved by vendoring fakerphp/faker anyway.
• Look elsewhere the moment any of these are true — which is essentially always for commercial Laravel work:
  • PHP 8.0+ or Laravel 9/10/11 is on the roadmap (this package will not follow you).
  • You need security patching, CVE response, or any support commitment. Archived projects offer none.
  • You need documentation, onboarding material, or hiring-pool familiarity — 7 stars and 0 dependents means no Stack Overflow corpus, no blog posts, and no engineer who has seen it before.
  • You need PSR-4 autoloading, modern PHPUnit/Pest integration, or compatibility with current Composer dependency graphs.
  • You need a license and maintenance review that survives procurement — an unmaintained transitive dependency is a finding in most vendor security reviews.
  • The underlying need is simply "realistic fixtures" — fakerphp/faker plus Laravel factories and seeders covers it with active maintenance and a large community.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated Hoa\Realdom, a PHP library for generating test data, as a candidate dependency. Recommendation: do not adopt, and remove it if it is already in the stack. It was last released in January 2017, the project is archived, it has seven GitHub stars and no downstream dependents, and it does not support current PHP or Laravel versions. The capability it provides is available from actively maintained, widely adopted alternatives at no cost. Adopting it would add maintenance and security-review exposure in exchange for zero differentiated value; the only real decision is whether an existing copy needs scheduled removal.

For engineering leads: This is a "contain, then delete" item, not a "fork and fix" item. It predates PHP 8, has no support channel, no release cadence, and no user base to lean on when it breaks — the maintenance cost is entirely ours with none of the upside. Where the need is realistic test data, standardize on fakerphp/faker behind Laravel factories and seeders so fixtures stay deterministic and reviewable. Where the need is property-based or randomized testing, evaluate a maintained modern equivalent rather than resurrecting a 2017 library. Action: grep composer.lock for hoa/, size the removal, and if it is genuinely load-bearing, timebox a spike to replace it in the current or next cycle — the risk is low today and grows monotonically with every framework upgrade.

Framing to avoid: do not present this as a failing of the team that added it. The library was reasonable when it was written; the environment moved and the project did not. The pitch is dependency hygiene — a small, cheap cleanup that keeps future upgrades unblocked — not a post-mortem.