Regex Laravel Package

Technical Evaluation

Architecture fit

• hoa/regex is a standalone, framework-agnostic PHP library: a PCRE grammar parsed through hoa/compiler into an AST, plus visitors (notably an isotropic/"random string matching this pattern" sampler). There is no Laravel service provider, facade, config, or contract — integration is purely PSR-4 autoloading plus our own wiring.
• That means it fits cleanly as a leaf dependency behind an interface we own, not as a request-path component. Realistic fits: (a) generating fixture/fuzz data from regexes in tests and seeders, (b) validating or analysing user-authored patterns (promo codes, SKU masks, validation rules), (c) a grammar/DSL feature where the AST is the point rather than the regex.
• It is a poor fit for anything the HTTP hot path depends on: parsing is LL(k) grammar work, generation can be unbounded, and there is no caching layer or Laravel-aware ergonomics to soften that.

Integration feasibility

• A single composer require hoa/regex pulls a sizeable abandoned transitive tree (hoa/compiler, hoa/ustring, hoa/math, hoa/stream, hoa/zformat, hoa/consistency, hoa/iterator, hoa/exception). Every one of those is part of the same defunct project, so risk compounds rather than staying local.
• Last release 2017-01-13, repository archived, and the dataset shows 0 dependents — a strong signal that no one is exercising this code against modern PHP. Expect PHP 8.x friction (removed functions, deprecations, setlocale/locale assumptions in hoa/ustring), and note that PHP moved to PCRE2 in 7.3, so a 2017-era PCRE grammar may mis-parse patterns that are valid today.
• Composer 2 will flag the package as abandoned at install time; there is no security-advisory channel, so composer audit gives us a false sense of coverage.

Technical risk

• Overall: high for production runtime, medium for build-time/test tooling.
• Correctness risk: an unmaintained PCRE grammar produces silent mis-parses rather than loud failures; generated strings are illustrative, not guaranteed-valid for edge constructs.
• Availability risk: catastrophic backtracking and unbounded sampling (*, +, nested quantifiers) can hang a PHP-FPM worker or exhaust memory. Never feed it untrusted patterns in-process.
• Upgrade risk: any PHP minor bump can turn deprecation notices into exceptions under Laravel's error handler, and there is no upstream to patch.

Key questions

1. What is the actual job-to-be-done — generating strings from a pattern, parsing/analysing patterns, or building a grammar/DSL? The answer changes the alternative set entirely.
2. Runtime or build-time? If it never runs in a request, the risk profile drops by an order of magnitude.
3. What is our PHP version matrix and upgrade cadence over the next 24 months?
4. Does our Composer/security governance permit abandoned dependencies, and who signs off on the exception?
5. Is the output correctness-critical, or merely illustrative test data?
6. Are we willing to own a fork, with a named maintainer and a review date?

Integration Approach

Stack fit

• No Laravel-native surface exists, so the only correct pattern is an internal port: define e.g. PatternSamplerInterface / PatternAnalyzerInterface in domain terms, implement it with a thin HoaRegexAdapter, and bind it in a service provider. No Hoa types (Hoa\Regex\Ast\*, visitors) may appear outside that adapter — this is what makes the eventual exit cheap.
• Keep it out of controllers and jobs that serve user traffic; put it in tests/, database/factories/, or an Artisan command.

Migration path

1. Timeboxed spike (2–3 days) on the target PHP version: install, sample a realistic pattern corpus, confirm parse success and generation behaviour.
2. Parallel-run: implement the same contract with an actively maintained alternative (evaluate s9e/regexp for parsing/analysis; Faker's regexify() for simple generation; hand-rolled generation for narrow, known pattern shapes) and diff outputs on the corpus.
3. Decide: adopt-with-fork, adopt-tooling-only, or replace. If adopting, fork into an internal namespace, patch PHP compatibility, and treat the fork as ours — do not depend on upstream.
4. Ship behind a config flag with the interface as the only call site, so a swap is a binding change.

Compatibility

• Pin an exact version, commit composer.lock, set config.platform.php to the deployed runtime, and run CI on the full supported PHP matrix so drift is caught before deploy.
• Add an explicit allowlist entry / documented exception for the abandoned package so future audits and onboarding engineers see the decision, not just a warning.
• Validate PCRE2-era pattern semantics (Unicode property classes, \R, possessive quantifiers, POSIX classes) against our corpus rather than trusting the 2017 grammar.

Sequencing Contract → spike → parallel-run comparison → decision → (if adopt) fork + CI matrix + flag → exit criteria and owner recorded. Do not let a spike turn into an implicit production dependency without step 3 being an explicit, written decision.

Operational Impact

Maintenance

• Upstream maintenance is effectively zero. Every fix, PHP-compat patch, and bug is ours, across eight-plus transitive packages we did not choose. Budget an annual line item tied to PHP upgrades, and assign one named owner — otherwise this becomes orphaned infrastructure with no one able to safely remove it.

Support

• No maintainer, no security process, no roadmap. Documentation is limited to source and stale API docs; support means source-diving Hoa's visitor/compiler idioms. That is acceptable for a tooling dependency with one consumer and unacceptable for a shared platform capability. Write an internal one-pager: supported pattern subset, known limitations, and who to ask.

Scaling

• Cost lands entirely on the calling PHP process (CPU for parsing, CPU+memory for generation). Unbounded quantifiers can produce combinatorial blow-up, so enforce hard limits: max generated length, max repetition count, wall-clock timeout, and a pattern allowlist/size cap.
• For any untrusted input, run it in a queue worker or dedicated CLI/service with resource limits — never synchronously in a web request. Throughput scales only by adding workers, which is a cost conversation worth having before adoption.

Failure modes

• Hangs from backtracking or unbounded sampling; memory exhaustion on large quantifier ranges.
• Silent mis-parse of modern/edge-case regexes (worse than an error, because tests pass with wrong fixtures).
• Fatal errors or deprecation-to-exception escalations after a PHP upgrade.
• Process-global side effects from hoa/ustring's locale handling leaking into number/date formatting elsewhere in the app.
• Composer install/audit friction and supply-chain findings with no fix path.

Ramp-up

• High relative to payoff: unfamiliar visitor/Zformat/LL(k) idioms, no onboarding material, and the useful surface (sampling, AST traversal) is small. Expect ~1–2 days for a competent engineer to reach a confident go/no-go, and a continuing tax thereafter.

TPM recommendation

• Given archived status, a 2017 last release, 0 dependents, and a 1.68 composite score, treat this as evaluate-and-replace, not integrate. Approve only as an isolated, dev-time/tooling dependency behind an owned interface, with a fork plan, resource limits, and a scheduled exit review; reject for any request-path or correctness-critical use.