Realdom Laravel Package

Technical Evaluation

What it is: hoa/realdom is an archived (last release 2017-01-13) standalone PHP library for generating realistic synthetic data using Hoa's grammar/compiler stack. It is not a Laravel package: no service provider, no facade, no config, and no integration with Laravel's factory/seeder/testing conventions.

Architecture fit: Poor for a Laravel application. Laravel's testing and seeding architecture is built around fakerphp/faker through model factories and seeders. Realdom would require a custom wrapper and a separate generation path, creating a second, parallel data-generation abstraction with no ecosystem support.

Integration feasibility: Low. The package is abandoned, has 7 stars, zero dependents, and the Hoa project is no longer maintained. Its 2017-era dependency graph (hoa/compiler, hoa/consistency, hoa/stream, hoa/zformat) carries PHP version constraints that will likely conflict with modern Laravel (PHP 8.1/8.2/8.3) and current Composer resolution. Adoption would require forking, vendoring, or running generation in an isolated legacy PHP container.

Technical risk: High.

• No security patching, no PHP 8 compatibility guarantees, and no maintainer response path.
• Composer conflict risk against Laravel 10/11 dependency sets; workarounds such as --ignore-platform-reqs are unsafe and non-reproducible.
• Deprecation/fatal errors likely under PHP 8.
• Low signal from the ecosystem: 7 stars and 0 dependents means almost no field validation.
• Opportunity score (18.82) and overall score (0.3225) reinforce that this is not a strategic dependency.

Key questions:

1. Is the actual need synthetic test/seed data, or a grammar-driven domain modeling capability?
2. Which Realdom feature is not already covered by fakerphp/faker plus custom providers?
3. Are we willing to own a forked, patched generator indefinitely?
4. Can the capability remain strictly dev/test-only to limit security and runtime exposure?
5. Would copying the grammar-based design pattern be more valuable than depending on the code?

Integration Approach

Stack fit: Not suitable as a runtime Laravel dependency. The only defensible use is as a dev-only reference or isolated CLI tool, never in production request paths. Laravel already ships with Faker via fakerphp/faker; Realdom's value would be its grammar-driven approach to realistic domains, not its implementation.

Migration path: Do not migrate existing Laravel factories/seeders to Realdom. If a team is attracted to its grammar-based generation model, prototype the behavior using a Faker custom provider or a small internal generator, then replace any Realdom API usage (realdom(), sampling helpers) with Faker calls. Treat Realdom as a design reference rather than a dependency to adopt.

Compatibility: Modern Laravel requires PHP 8.1+; Realdom's 2017 constraints will not reliably install. If a spike is unavoidable, isolate it in a Docker image pinned to PHP 7.x, fork the package under the organization's namespace, and keep it out of the application autoloader. Do not use platform-requirement overrides in the main application.

Sequencing:

1. Run a short discovery spike in an isolated legacy container to confirm whether any unique grammar capability exists.
2. Compare outputs and developer experience against fakerphp/faker with custom providers.
3. Make a build-vs-buy-vs-reference decision; default to reference-only.
4. If adopted, fork, add PHP 8 compatibility, pin versions, and wrap as a dev-only internal package with an explicit owner.
5. Otherwise, document the decision and standardize on Laravel's native Faker-based tooling.

Operational Impact

Maintenance: Effectively zero upstream maintenance. Adopting it transfers full ownership to the internal team: PHP compatibility patches, dependency updates, security triage, and documentation. For a test-data generator this is rarely justified.

Support: No vendor, no active community, sparse 2017-era documentation. Incident resolution would depend on internal archaeology of Hoa's grammar and compiler internals.

Scaling: Data generation is offline and CPU-bound, so runtime scaling is not a concern. At high seed volumes, grammar compilation and sampling may show memory and performance limits, but this is secondary to the maintenance risk.

Failure modes:

• Composer dependency resolution failure against modern Laravel/PHP.
• PHP 8 deprecation warnings escalating to fatal errors.
• Grammar compilation failures with poor diagnostics.
• Silent behavioral drift after forking or patching dependencies.
• Supply-chain exposure if the abandoned package is pulled into production images.

Ramp-up: Steep for low return. Engineers must learn Hoa's grammar DSL and package conventions, with little documentation and no community examples. By contrast, Faker is already familiar to Laravel developers and integrated into the framework's tooling.

TPM recommendation: Do not adopt hoa/realdom as a Laravel dependency. Leverage it only as an architectural reference for grammar-driven synthetic data if that specific capability is required, and otherwise standardize on fakerphp/faker with custom providers, Laravel factories, and seeders.