Visitor Laravel Package

Product Decisions This Supports

• Extensibility architecture for tree-shaped domain models. If the roadmap includes anything that is naturally a tree — a form/field schema, a visual workflow or rule builder, a page builder block tree, a permission/org hierarchy, a query or expression model — the Visitor pattern is the right structural choice for keeping traversal, validation, rendering, and serialization logic out of the model classes. This package is the canonical PHP articulation of that pattern, so it is useful as a design reference when the team is deciding how to structure those features.
• Build vs. buy on traversal infrastructure. Hoa\Visitor is essentially two interfaces (Visitable, Visitor) plus a small dispatch helper. That is a 30–80 line concern. It sharpens the build-vs-buy conversation by making the answer obvious: the "buy" side has near-zero cost and near-zero value, so the decision collapses to "write it ourselves."
• Roadmap gating for DSL / AST work. If the product is heading toward a templating engine, a linting/analysis feature, a transpiler, or an expression evaluator, this pattern becomes load-bearing and worth an explicit architecture decision record. If none of that is on the roadmap, the package is irrelevant and should not consume planning time.
• Concrete use cases worth naming when scoping: Blade-style template compilation, a marketing-campaign rule engine, an import/export pipeline that transforms nested payloads, a report builder walking a metric tree, or a static-analysis surface for user-authored formulas. In each case the pattern is the asset; this package is not.
• Dependency hygiene as a standing decision. With 0 dependents, no release since January 2017, and an archived repository, this is a clean worked example for a "do not vendor abandoned code for trivial concerns" policy — useful precedent when the same question comes up again.

When to Consider This Package

Consider it only as a reference implementation, not as a dependency. Specifically:

• A senior engineer is sketching the interface shape for a new visitor-based subsystem and wants a well-known, minimal prior art to compare against. Reading this repo takes ten minutes and costs nothing.
• You are auditing legacy code that already pulls in Hoa components (the wider Hoa project was a modular PHP library suite) and need to understand the contract before replacing it.

Look elsewhere — or write it yourself — in every other case. The disqualifying facts are concrete:

• Archived and frozen since 2017. No security patching, no PHP 8.x compatibility work, no maintenance path. Composer constraints from that era routinely conflict with Laravel 10/11 environments running PHP 8.1+.
• Zero dependents. There is no ecosystem, no battle-testing at scale, and no community to inherit maintenance from. The 262 stars are historical interest, not adoption.
• The abstraction is not defensible. You cannot build a competitive advantage on two interfaces. Copying the idea into app/Support/Visitor/ takes less time than evaluating the dependency and gives you full control of the contract.
• Better maintained alternatives exist for the adjacent, heavier problems. If the actual need is AST traversal (a common Laravel-adjacent case — think static analysis, codegen, or a custom templating layer), use a maintained parser's own visitor infrastructure rather than a generic pattern library. If the need is pipeline-style transformation, Laravel's own pipeline primitives already cover it.
• Do not adopt it as a transitive dependency of a broader Hoa-based framework. That is the one scenario where the risk is real rather than theoretical, and the right response is to plan the exit, not the integration.

How to Pitch It (Stakeholders)

To executives: This is not a product dependency, and I recommend we do not add it. It is a small, archived PHP library from 2017 that implements a well-understood software design pattern. The pattern is worth using; the package is not — it has no users we can point to, receives no updates, and would introduce an unmaintained component into our stack for a problem we can solve in an afternoon of engineering time. The cost of "buying" is low but the risk is disproportionate to a benefit that rounds to zero. Decision: adopt the pattern internally where it fits, decline the dependency.

To engineering: The Visitor pattern is the right answer for our tree-shaped models — form schemas, rule builders, block trees — because it keeps traversal and rendering logic out of the domain objects and makes adding a new operation (validate, render, export, diff) a new class rather than an edit to every node type. Hoa\Visitor is a clean articulation of that contract and is worth fifteen minutes as prior art. It is not worth a composer require: it has been archived since 2017, has zero dependents, and its PHP version constraints will likely conflict with our Laravel runtime. We should define Visitable / Visitor ourselves in application code, keep the surface minimal, and revisit only if a genuinely maintained AST tooling need appears — at which point we evaluate the maintained parser's visitor layer directly rather than a generic pattern library.