Compiler Laravel Package

Technical Evaluation

Architecture fit. hoa/compiler is a standalone, framework-agnostic PHP library for grammar-based parsing: it ships lexers, LL(1)/LR(1) parser generators, a grammar description language (.pp files), and a visitor/traversal API. That makes it a candidate only for a narrow class of problems — you own a domain-specific language, a config/markup format, an expression or query grammar, or a protocol you need to validate structurally. It is explicitly not a Laravel component: there is no service provider, no facade, no config publishing, no queue/console/HTTP integration. In a Laravel codebase it would sit as a plain Composer dependency behind an application service class, not as part of the framework layer. For CRUD, templating, or request validation work it is the wrong tool; for "we need to parse a non-trivial grammar we control," it is a mature, feature-complete implementation of textbook parsing techniques.

Integration feasibility. Composer installation and in-process use are straightforward — no extensions, no external services, no build step beyond including grammar files. The real cost is competence, not plumbing: your team must author grammars in Hoa's DSL, understand LL(1) vs. LR(1) tradeoffs and conflict resolution, and design AST visitors. Expect a proof-of-concept to take days, not hours, and to be gated on grammar design skill rather than Laravel knowledge.

Technical risk. High and structural. The package is archived, with a final release in August 2017 and no upstream maintainer. It and its Hoa dependency chain (hoa/core, hoa/stream, hoa/iterator, hoa/zformat, etc.) predate modern PHP; PHP 8.x compatibility is unverified at best and likely to require patches. There are no security advisories, no CVE monitoring, and no fixes — any vulnerability found is yours to remediate. Zero dependents in the surveyed ecosystem means no peer support, no community answers for modern PHP, and documentation that has largely rotted with the project site. That combination — abandoned upstream, unmaintained transitive dependencies, niche API — is the classic profile of a package that quietly becomes load-bearing technical debt.

Key questions.

• Do we actually need a general grammar engine, or would symfony/expression-language, nikic/php-parser, or a hand-written recursive-descent parser cover the requirement at a fraction of the risk?
• Does it run cleanly on our target PHP version (8.1/8.2/8.3), and can we prove that in a time-boxed spike?
• What is our exit plan if the grammar we need hits an LL(1)/LR(1) limitation the library cannot express?
• Who on the team owns grammar expertise, and what happens when they leave?
• Would forking and vendoring the package (accepting maintenance ownership) be cheaper than adopting a maintained alternative?

Integration Approach

Stack fit. Treat it as an isolated parsing kernel, not an application dependency. Bind it behind a narrow, application-owned interface (e.g. GrammarParser::parse(string): Ast), keep .pp grammar files in the repo under version control, and ensure no controller, job, or model ever imports a Hoa\ class directly. This keeps the blast radius to one or two classes and makes substitution a contained change.

Migration path. There is nothing to migrate from; the question is how to adopt without lock-in. Sequence: (1) interface and DTOs first, defined against your domain, not against Hoa's AST; (2) a spike implementation using hoa/compiler behind that interface; (3) a competing spike using a maintained alternative; (4) choose on evidence. If hoa/compiler wins, pin the exact version, commit the lockfile, and vendor the source into a private fork so an upstream disappearance cannot break installs.

Compatibility. Validate on the exact PHP version running in production and the next one you plan to upgrade to, before committing. Audit the full Hoa dependency tree (not just the top-level package) for PHP 8 deprecations and removals. Run composer audit and expect a permanently noisy dependency graph — decide in advance how that noise is triaged so it does not mask real findings. If the app must run PHP 8.x and the library will not, the fallback is a separate PHP 7.x sidecar service — which is a very expensive way to parse a string, and should push you toward an alternative.

Sequencing. Freeze scope (grammar, sample inputs, error-reporting requirements), spike, decide build-vs-adopt, then implement with a golden-file test suite over a corpus of real inputs. Do not let the grammar grow organically in production; grammar changes need review and regression tests just like schema changes.

Operational Impact

Maintenance. You are the maintainer. There is no upstream to file issues against, no release cadence, no backports. Budget ongoing engineering time for PHP-version compatibility work and for any bug you encounter — the answer will always be "fix it ourselves."

Support. Effectively zero: no vendor, no active community, no current documentation, no security response process. Internal knowledge concentration is the dominant support risk; document the grammar and the parser's quirks, and rotate at least two engineers through the code.

Scaling. Parsing is in-process CPU and memory work. Small inputs are fine; large or adversarial inputs are not — grammar and input combinations can cause deep recursion, memory exhaustion, or pathological parse times. For anything user-supplied, cap input size, run parsing in queued jobs with timeouts and memory limits rather than in the request cycle, and treat parse failures as a distinct, observable error class. Cache compiled grammars or parser instances where the API allows, rather than rebuilding per request.

Failure modes. Watch for: silent PHP-version breakage after a base-image upgrade; transitive dependency rot breaking composer install from a cold cache; unbounded recursion or memory exhaustion on hostile input; ambiguous or conflicting grammars producing confusing errors at authoring time; and the quiet scenario where the original author leaves and nobody can safely change the grammar.

Ramp-up. Steep for this package specifically. Engineers need formal-language fundamentals (LL(1)/LR(1), FIRST/FOLLOW sets, conflict diagnosis), Hoa's grammar DSL, and the visitor pattern as the library implements it — and they will be learning it without working documentation. Realistically, weeks of ramp-up for the first contributor, versus days for a maintained general-purpose parser. Factor that into the build-vs-adopt decision; for most Laravel teams, the honest answer is that a narrower, maintained tool will deliver the same business outcome with far less of this list attached.