Regex Laravel Package

Product Decisions This Supports

• Test-data and fixture generation. The one capability worth a spike is generating strings that satisfy a given pattern (seeded/fuzzed fixtures, synthetic payloads for QA, sample data for demos). This is a "save a sprint on test tooling" decision, not a product feature.
• Regex introspection and safe-input review. If your product lets users supply patterns (routing rules, alert filters, validation rules, log-search syntax), you need to parse and reason about those patterns rather than just preg_match them — complexity estimates, ReDoS exposure, normalizing/explaining a pattern back to the user. This is a genuine product-safety decision; the package is a candidate implementation detail, not the decision.
• Internal DSL / grammar tooling. Relevant if a roadmap item involves a small domain language (query syntax, rule engine, template language) and the team is weighing a hand-rolled lexer against an off-the-shelf parser stack. Note this package historically sits underneath Hoa's compiler stack, so adopting it usually implies evaluating that larger, equally stale chain.
• Build vs. buy vs. fork. The real decision this surfaces is procurement posture: with zero dependents and no maintainer, "adopt" effectively means "vendor and own." Frame it as a fork-with-a-license, budgeted as internal maintenance, not as a third-party dependency.
• Roadmap non-decision. It should not anchor a customer-facing SLA, a performance-sensitive hot path, or anything on a PHP 8.1+ upgrade path. Treat it as a spike-level input to a tooling decision, and expect the honest outcome to be "use native PCRE, or an actively maintained alternative."

When to Consider This Package

Consider it only when all of the following hold:

• You need to manipulate or generate from regular expressions (build an AST, sample matching strings, analyze structure) — not merely match text, which native PCRE already does well.
• The work is internal tooling (test factories, CI linting, an admin-only analyzer) with no uptime or latency commitments.
• Your runtime is pinned to PHP 7.x, or you have the appetite to patch PHP 8 compatibility yourself.
• The surface area you touch is small and isolated behind your own interface, so replacing it later is a one-file change.
• You are comfortable vendoring the source and accepting that security fixes are yours to write. The permissive license makes this legally easy; it does not make it cheap.
• You've confirmed the alternative (a maintained parser/grammar library, or a thin wrapper over preg_* plus a targeted third-party analyzer) doesn't already cover the need.

Look elsewhere — or stop — when any of these are true:

• You're on Laravel 10/11 or PHP 8.1+, or you have an upgrade on the roadmap. A 2017 archive is a predictable blocker at exactly the wrong moment.
• The requirement is production behavior: request validation, routing, search, anything a customer notices.
• You need performance guarantees, Unicode edge-case correctness, or documented security posture.
• You'd be pulling it in transitively through other Hoa components — that turns one stale dependency into a frozen subtree you now own.
• The need is simply "match a pattern." That's preg_match, symfony/string, or a Faker regexify helper. Do not add a dependency to do what the language does.

How to Pitch It (Stakeholders)

To executives (one paragraph). This is a small, free, open-source PHP library for working with regular expressions at a structural level. It has been unmaintained since 2017, has no downstream dependents, and is formally archived — meaning nobody is fixing bugs or security issues. The recommendation is not to adopt it as a platform dependency. Its only defensible use is a short, time-boxed engineering spike against an internal tooling need (test-data generation or analyzing user-supplied patterns for safety), where the fallback is native PHP functions. Cost of the spike is a few engineer-days; cost of adopting it as infrastructure is an indefinite, unbudgeted maintenance commitment we'd be taking on quietly. If the spike proves the capability matters, we should fund a maintained alternative or a small in-house implementation rather than inherit this one.

To engineering (the ask). Time-box a spike: (1) verify it installs and passes a smoke test on our actual PHP version, (2) prototype the one capability we care about behind our own interface, (3) benchmark it against the native-PCRE baseline and any maintained alternative. Success criteria are functional fit and a clean exit path, not elegance. If it fails the PHP-version check or needs more than a trivial shim, close it out. If we proceed, we vendor the source into our repo, own the patches, document the fork point, and keep the integration behind a single adapter class so a future swap is contained. Default position absent a compelling spike result: use native preg_* and revisit the parser question when an actively maintained library fits the need.