Compiler Laravel Package

Product Decisions This Supports

• Build vs. buy for parsing/DSL capability. The core decision this package informs is whether to hand-roll a parser or adopt a grammar-based toolkit. hoa/compiler provides the full pipeline — lexer, LL(1)/LR(1)/LALR(1) parser generation, AST construction, and visitor traversal — so a team can define a grammar in the PP language rather than writing brittle regex or recursive-descent code.
• Feature bets that require a domain-specific language. Justifiable when the roadmap includes user-authored expressions, rules, or configuration: pricing/formula engines, workflow or policy rule sets, query/filter languages for an admin UI, template or markup dialects, importers for third-party file formats.
• Buy vs. build at the ecosystem level. For Laravel products, the realistic alternatives are narrower: symfony/expression-language for safe expression evaluation, nikic/php-parser for PHP source, doctrine/lexer for tokenizing, or offloading to ANTLR/PEG tooling. Choosing hoa/compiler is choosing "full grammar toolkit, self-hosted," which is a materially larger commitment than any of those.
• De-scoping signal. With 0 dependents and an archive date of 2017, adopting this is a build-and-own decision, not a dependency decision. That changes the approval path: it should be framed as vendoring/forking a frozen component with an internal owner, not as adding a Composer package.
• Roadmap timing. Because the library is stable-but-dead, the correct moment is an isolated, well-bounded parsing need with a tolerant timeline — not a load-bearing path in a product expected to evolve for years.

When to Consider This Package

Consider it when:

• The need is genuinely grammatical (nested structures, operator precedence, ambiguity) and a regex or hand-written parser has already failed or is visibly accreting risk.
• The stack is PHP-only and the parsing must run in-process, with no service hop or FFI boundary.
• Someone on the team is comfortable with compiler concepts: LL/LR/LALR trade-offs, grammar conflicts, and AST visitor patterns. The PP grammar language is expressive but has a learning curve.
• The grammar is small-to-medium, changes infrequently, and is owned by a single team that can maintain a fork pinned to a commit.
• You have accepted the operational cost: security review of an unmaintained tree, PHP 8.x compatibility verification, and a documented exit plan.

Look elsewhere when:

• The requirement is expression evaluation only — symfony/expression-language covers most Laravel cases with active maintenance and a safer evaluation sandbox.
• The input is PHP source itself — nikic/php-parser is the maintained, widely depended-on answer.
• You need vendor support, SLAs, security patches, or a current release cadence. The 2017 last release and archived status are disqualifying for regulated or long-lived surfaces.
• Performance is a hard constraint: large inputs, streaming, or per-request parsing at volume all argue for benchmarking against a maintained alternative first.
• Interop matters — grammar portability to other languages, or a need to share the grammar with non-PHP services.
• The parsing need can be eliminated by schema or format change. That is usually the cheapest decision available.

How to Pitch It (Stakeholders)

To executives: This is a compiler-construction toolkit, not a Laravel component. It would let us implement a small language — rules, formulas, or a query syntax — in weeks rather than quarters, which is real leverage if that language is a product differentiator. The catch is ownership: the project was archived in 2017, has no meaningful downstream ecosystem, and will receive no upstream fixes. So the proposal is not "add a dependency," it is "adopt and maintain a frozen internal component." That is defensible for a bounded, differentiated feature and indefensible for infrastructure we expect to live for years. Recommendation: fund a timeboxed spike against a named feature, and require a written fallback before committing.

To engineering: Strong conceptual coverage — grammar-driven lexing and parsing, AST generation, and visitor-based traversal, with a mature design that predates most PHP parsing libraries. The interface is expressive and the visitor model composes well with Laravel service containers and pipeline-style processing. The risks are equally concrete: no releases since 2017, archived repository, zero dependents to inherit fixes from, and unknown PHP 8.x behavior that we would have to validate ourselves. If we proceed, treat it as a vendored fork with a named maintainer, pinned version, characterization tests around the grammar, and a documented replacement path. If the actual requirement is expression evaluation, say so early — we can solve that with a maintained library and skip this entirely.