Url Laravel Package

Product Decisions This Supports

• Legacy feature upkeep, not new bets. This package only informs decisions about code that already depends on it: URL parsing in link shorteners, canonical/SEO URL generation, sitemap builders, affiliate and campaign-tracking parameter normalization, and redirect-handling middleware. It should not anchor any roadmap item.
• Build vs. buy — settled, and you should "buy" elsewhere. URL parsing is a commodity. The only real decision left is which commodity: league/uri (same vendor, actively maintained), Laravel's native Illuminate\Support\Uri facade (Laravel 11+, itself built on league/uri), or symfony/http-foundation if you're already in that ecosystem. Do not build a parser in-house; do not build on this.
• Migration sequencing — unchanged, but correct the record. The 3.3.5 patch (a single bug fix to relative-path resolution, via PR #81) disproves the shorthand that this package has been untouched since 2015-07-15. Treat it as dormant with sporadic patch activity, not archived-and-frozen. That distinction does not change the decision: one merged community PR is not a roadmap, a support commitment, or a security process. Ecosystem lock-in remains negligible (low adoption score, effectively zero dependents), so migration risk is contained to your own codebase — a cheap, schedulable cleanup ticket rather than a program of work.
• Behavioral surface of the patch release. 3.3.5 changes the output of relative-path resolution. If any call site asserts on, stores, or diffs parsed paths, a patch-level bump can shift results — verify before upgrading, and pin the version you land on. This is a maintenance-cost signal, not a feature signal.
• Security posture decisions around user-supplied URLs. Any feature that validates hostnames, blocks SSRF, sanitizes open-redirect targets, or enforces allow-lists depends on parser correctness. A bug fix to relative-path handling is not hardening: the package still carries no evidence of work on the edge cases (IDN, backslash/@ confusion, scheme-relative URLs, IPv6 literals) that attackers have exploited since the PHP 5/7 era. This remains the single decision where the package materially matters — whether to tolerate parser drift in a security-adjacent path.
• The "opportunity" score is a replacement opportunity, not an adoption one. Read the 18.32 opportunity figure as the size of the modernization gap, not as latent demand. A lone patch release may nudge a naive staleness metric; it does not create demand. It argues for deprecation planning, not a proof-of-concept.

When to Consider This Package

Consider it only in the narrow case where you are maintaining an existing application that already imports it and the code path is non-security-critical (e.g., cosmetic URL formatting in an internal admin tool), and a migration would cost more than the residual risk. Even then, pin it (to 3.3.5 or your verified equivalent), document the decision, and schedule removal. The 3.3.5 release does not widen this window — a patch does not create a maintenance guarantee, and you should not read it as a signal to defer migration indefinitely.

Look elsewhere in every other circumstance:

• New code, any language version. Use league/uri — same maintainer organization, PSR-7/PSR-17 aligned, actively released with a real roadmap.
• Laravel 11+. Use the framework-native Uri class; it wraps league/uri and gives you first-class support with no independent dependency to track.
• Anything parsing untrusted input — redirect targets, webhooks, callback URLs, avatar/proxy fetchers, link previews. An intermittently-maintained parser remains an unacceptable risk surface here.
• Any project on a supported PHP runtime (8.x). This package's API lineage predates PHP 7; the 3.3.5 patch does not raise or restate a supported-PHP floor, so compatibility remains unverified and unsupported.
• Teams needing a support contract or CVE response. MIT + low activity + zero dependents means there is no one to escalate to. A community pull request is not a CVE process. If your product requires a vendor security SLA, this fails the threshold outright.

How to Pitch It (Stakeholders)

To executives (30 seconds): We found a dormant PHP URL-parsing library in our dependency scan. It has been without a roadmap or maintainer commitment for roughly a decade; its only recent change is a single volunteer bug fix to relative-path handling, with no security process behind it. URL parsing is the layer that decides whether a redirect goes where we intend, so a stale parser is a security and reliability liability we're carrying for no benefit. There is a maintained successor from the same organization, and modern Laravel has equivalent functionality built in. Recommendation: do not adopt; approve a scoped migration off it. Cost is low because almost nothing else in the ecosystem depends on it — the work is confined to our own call sites. Do not let the recent patch read as a reason to wait.

To engineering (the practical version): league/url remains deprecated in all but name. 3.3.5 is a one-line-class bug fix to relative-path get(), not a revival — no new features, no deprecation reversal, no supported-PHP restatement. Its API is broadly reproducible with league/uri or, on Laravel 11+, Illuminate\Support\Uri — but treat it as a rewrite of call sites, not a version bump: constructor semantics, immutability, and query-parameter handling differ, and league/uri is stricter about validation (which is the point). If you must stay temporarily, pin to 3.3.5 and re-run any test that asserts on resolved paths, since the patch changes relative-path output. Suggested path: (1) inventory call sites and classify each as cosmetic vs. security-adjacent; (2) migrate security-adjacent paths first — redirects, host validation, anything touching user input; (3) add a dependency-policy check to CI so a package with no release in N years, or no stated support window, fails the build. Ask for the inventory as the first deliverable, not an estimate — we don't yet know the blast radius, and given zero dependents it's likely small.

To security/architecture, if they push back: the honest counterargument is that the library is small, MIT, vendorable, and evidently still receives occasional patches — we could fork and patch. Reject that. Forking means we own URL-parsing edge cases forever, and a volunteer bug fix to path resolution is not the same as an owner accountable for parser hardening. That is a worse trade than a half-day migration to a maintained package that already does it.