Uri Schemes Laravel Package

Product Decisions This Supports

• Link-handling features across the product surface. Anything that accepts a URL from a user or a third party — profile/website fields, avatar and image URLs, webhook endpoints, calendar subscriptions (webcal://), OAuth/SSO redirect allowlists, mobile deep links (myapp://), and canonical URLs for SEO — benefits from a real URI parser instead of regexes and filter_var string checks. This package is the scheme-aware layer of that capability: it models schemes like mailto:, tel:, urn:, ftp:, ssh:, and git: as structured objects, so you can read out the address, subject, phone number, or path components rather than string-slicing.
• Build vs. buy. Buying is the right default here: MIT-licensed, narrow scope, ~a few thousand lines, and parsing RFC 3986/5322-adjacent grammar is a classic "do not hand-roll" area. The PM decision is therefore not "build vs. buy" but "this package vs. its successor" — see below. The recommendation is to buy the capability, just not from this repo.
• Roadmap input on the URI stack. Adoption of anything in the league/uri family should be planned as a platform-level dependency decision (one owner, one upgrade path), not a per-team choice. A team pulling in this package in 2024+ is a signal that the org lacks a sanctioned URI/URL-parsing standard — worth fixing centrally.
• Data-quality and trust-and-safety work. URL canonicalization and deduplication for analytics, link shorteners, moderation/blocklist pipelines, and "is this the same link" comparisons. Scheme-aware parsing materially reduces false negatives here (e.g., treating mailto: and https: links with different rules).
• Concrete product use cases to scope: contact import and email-signature parsing (mailto, tel), feed readers and RSS/Atom link extraction, ActivityPub/IndieWeb identities (acct:, web+* schemes), payment and messaging links (bitcoin:, upi:, sms:), and calendar deep links.
• What it is not: it is not an HTTP client, not a DNS/SSRF safety layer, and not a full URL validator. Do not let it be sold internally as "our security fix for redirects."

When to Consider This Package

Consider it only as a legacy-compatibility move, when all of the following hold:

• The codebase is pinned to PHP 5.6/7.0–7.2-era dependencies and an existing Composer graph that already resolves league/uri below v6 (verify the exact constraint in composer.json before planning anything).
• You specifically need the scheme component objects (Mailto, Tel, Urn, Ftp, etc.) as distinct classes, and you need them today, without a refactor.
• The parsing is on a non-security-critical path (display formatting, analytics normalization, feed link extraction) where a bug is a degraded UX, not an incident.
• You accept that this is a stopgap with a dated migration ticket attached.

Look elsewhere — this is the default for anything new — when:

• The repository is archived and last released 2018-11-26. That means no security patches, no PHP 8.x compatibility fixes, no deprecation cleanup, and no maintainer to escalate to. In a modern PHP 8.2/8.3 Laravel app this is a hard no, especially for anything that touches redirect allowlists, SSRF filtering, or user-supplied link validation.
• You are on a current stack. Take the same capability from league/uri v6/v7, which absorbed the scheme components into the main package. Same API lineage, maintained, PHP 8-ready. The migration cost is measured in hours, and it removes the archived-dependency question entirely.
• Your framework already covers it. Laravel's url validation rule, Str::isUrl(), URL::isValidUrl(), and filter_var($x, FILTER_VALIDATE_URL) handle the large majority of "is this a URL" checks. Only escalate to a parser when you genuinely need scheme-specific components.
• You need a specialized concern instead. Use egulias/email-validator for mailto: address parts, a phone-number library for tel:, or symfony/http-foundation/psr/http-message URI implementations if you already depend on them.
• Ecosystem signal matters to your risk model. 210 stars, 0 dependents, and a low opportunity score (18.6) describe a package with essentially no downstream validation. Treat it as a research signal about the league/uri family, not as an adoption candidate. Nothing is testing this on your behalf.

Decision summary: approve the capability, reject this artifact. Fund a small migration to league/uri v7 (or rely on framework primitives) rather than adding league/uri-schemes to composer.json.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small, free, MIT-licensed library for parsing links — the kind of code behind "paste your website," webhook setup, calendar subscriptions, and redirect allowlists. The capability is worth having; hand-written link parsing is a recurring source of bugs and quiet security gaps. However, this specific package has been archived since 2018 with no releases, no maintainer, and no downstream users, so we do not recommend adopting it. The good news is the maintained successor is from the same authors and costs the same (free): roughly one engineer-day, no new vendor, no license spend, and it eliminates an unmaintained dependency from our stack before it becomes an audit finding. Recommendation: adopt the maintained successor, decline this package, and standardize link parsing org-wide so individual teams stop making this call.

To engineering (the actual ask):

• Do not add league/uri-schemes to composer.json. It is archived, PHP 5.6/7.x-era, unpatched, and has zero dependents — no one is finding its bugs for us.
• Use league/uri ^7 (or ^6 if constraints require) for scheme components — same API lineage, maintained, PHP 8.x compatible, security fixes flowing.
• Before writing any code, check whether the requirement is already met by Laravel's url rule, Str::isUrl(), or URL::isValidUrl(). If it is, this is a zero-line change.
• Where the requirement is genuinely scheme-specific (mailto: addresses/subjects, tel: numbers, urn: namespaces), wrap the parser behind a single internal service (e.g., LinkParser) so the vendor is an implementation detail and a future swap is one file, not fifty call sites.
• Do not route security decisions — redirect allowlists, SSRF filtering, blocklists — through an unmaintained parser. Those paths get the maintained library plus explicit allowlist logic and tests.

Risk framing to use in the review: the cost of the maintained path is ~1 day; the cost of the archived path is an unbounded tail of unpatched parsing behavior in user-facing and potentially security-adjacent code, with no upstream to call. That trade is not close.