Uri Util Laravel Package
spomky-labs/uri-util
A lightweight PHP utility for parsing, normalizing, and manipulating URIs and URI references according to RFC 3986. It helps resolve relative paths, inspect components, and build reliable URL handling in frameworks and libraries without heavy dependencies.
Technical Evaluation
Architecture fit. spomky-labs/uri-util is a standalone PSR-7 UriInterface implementation with ergonomic helpers for path, query-string, and fragment manipulation. It is not a Laravel package — no service provider, no facade, no config, no Illuminate coupling. Architecturally it sits at the very bottom of the stack as a value-object library. That is a good layer to occupy, but Laravel already occupies it: guzzlehttp/psr7 (shipped transitively via laravel/framework → guzzlehttp/guzzle) provides GuzzleHttp\Psr7\Uri, and league/uri is the de facto PHP standard for anything beyond basic PSR-7 compliance. Adopting a third URI implementation alongside those two creates competing UriInterface implementations that are not interchangeable without conversion — a real source of subtle bugs at boundaries (HTTP client, signed URLs, redirects, OAuth callbacks).
Integration feasibility. Low friction to install, high friction to justify. There is no Laravel integration surface to build, so "integration" means: add the dependency, write adapters at every boundary where a Psr\Http\Message\UriInterface crosses into Laravel internals (Guzzle client, Illuminate\Http\Client, Symfony Request), and own those adapters forever. The one legitimate integration pattern is as a transitive dependency — if a web-auth/* or similar package pulls it in, you scope it, pin it, and never touch its API directly.
Technical risk. This is the dominant section, and the verdict is unfavorable:
| Risk | Assessment |
|---|---|
| Maintenance status | Package is effectively abandoned/superseded; the author's own guidance points to league/uri. No releases, no security policy, no active CI. |
| PSR-7 v2 incompatibility | psr/http-message 2.0 added return types to UriInterface. A v1-era implementation will fatal on class ... must be compatible with Psr\Http\Message\UriInterface. Modern Laravel (10/11/12) resolves psr/http-message ^1.0|^2.0; Composer may pick 2.0 and break at runtime, or pin 1.0 and fork your dependency graph. Verify the declared constraint before anything else. |
| Signal strength | Score 0, no stars, zero dependents. In a solved domain with three mature incumbents, this is not a "hidden gem" — it is a dead node. |
| Security surface | URI parsing is attacker-adjacent (SSRF validation, open-redirect checks, host allowlists, signed-URL canonicalization). An unpatched parser is a liability, not a convenience. |
| Bus factor | Single author, no succession plan, archived repo. |
Key questions. (1) Do we actually need this, or did it arrive as a transitive dependency we can pin or exclude? (2) Which psr/http-message major does it declare, and does that conflict with our locked graph? (3) What specific behavior do we need that GuzzleHttp\Psr7\Uri or League\Uri\Uri does not provide — and can we prove it with a failing test? (4) Is there any code path where this library's URI object is used for security decisions (host validation, redirect targets)? (5) Can we fork it internally under MIT if a transitive dependency forces it in?
Integration Approach
Stack fit. Poor as a first-class choice. The idiomatic Laravel mapping is:
- Simple manipulation (build/parse a URL, append query params):
parse_url,http_build_query, orGuzzleHttp\Psr7\Uri— zero new dependencies. - RFC-compliant, normalization-aware work (IDN, percent-encoding edge cases, URI templates, relative resolution):
league/uri+league/uri-components. This is the direct successor and the correct target. - Framework-level URL generation:
url(),route(),URL::signedRoute()— do not bypass these with a custom URI object.
Migration path. Treat any existing usage as technical debt with a two-step exit: (a) introduce a thin internal UriFactory/Url wrapper that returns a Psr\Http\Message\UriInterface from GuzzleHttp\Psr7\Uri; (b) replace SpomkyLabs\UriUtil\Uri constructions with calls to the wrapper. Because the library implements a standard interface, call sites that only consume UriInterface need no change — the blast radius is limited to direct construction and any non-interface helpers (getQueryParams, path normalization). Port those helpers to dedicated unit-tested methods on the wrapper.
Compatibility. Confirm PHP constraint breadth (^7.x will install on 8.x only if the upper bound is open or >=), and confirm the psr/http-message major. If it requires ^1.0 and you are on Laravel 11/12, expect a resolver conflict or a runtime interface-compatibility fatal. Also check psr/http-message v2's typed returns against the class methods — this is the single most likely hard blocker.
Sequencing. Do not sequence toward adoption. Sequence the exit: (1) inventory direct and transitive usage; (2) if transitive-only, pin explicitly and add a composer why check to CI so it never becomes direct; (3) if direct, build the wrapper, migrate call sites, delete the dependency; (4) add a static-analysis rule (PHPStan/Psalm) banning the namespace from reappearing. Target completion within a single iteration — this is a small, low-risk refactor relative to the risk it retires.
Operational Impact
Maintenance. Effectively infinite maintenance burden for zero upstream support: every PHP minor bump, every psr/http-message major, every security advisory in the URI/HTTP space becomes your problem to triage, patch, and re-vendor. Compare against league/uri, which absorbs that cost for you. This is the single strongest argument against adoption and the strongest argument for expedited removal.
Support. No commercial support, no maintainer responsiveness, no CVE process, no changelog cadence. Internal engineers debugging a percent-encoding or IDN edge case will find no upstream to escalate to, and community answers will all point to the alternative libraries.
Scaling. Performance is a non-issue — URI parsing is negligible in any realistic request path. The scaling concern is organizational: N services × one bespoke URI implementation = N incompatible notions of "normalized URL," which surfaces later as cache-key divergence, signature mismatch (OAuth/OIDC redirect_uri, HMAC-signed URLs), and duplicate-content bugs. Standardize on one implementation org-wide; this package will not be it.
Failure modes. Ranked by likelihood: (1) hard fatal on psr/http-message v2 upgrade during a routine Laravel major bump; (2) silent divergence between this URI's normalization and Guzzle's, breaking signed URLs and redirect validation; (3) inability to patch a parser-level vulnerability, forcing an emergency fork under incident pressure; (4) contributor confusion — two UriInterface types in the container with no clear rule for which to use.
Ramp-up. Trivial — the API is small and conventional, and a mid-level PHP engineer is productive in under a day. That is precisely why the switching cost is also trivial, and why sunk-cost reasoning should not be used to defend it. Budget the ramp-up time against league/uri instead; it is marginally larger but buys a maintained surface, RFC test-suite coverage, and a successor community.
Recommendation. Do not adopt for new work. If present, treat as an exit item with a same-sprint target, except where a transitive dependency pins it — in which case isolate, pin, and gate it in CI. Replace with GuzzleHttp\Psr7\Uri for interface-level needs and league/uri for anything requiring standards-compliant parsing or normalization.
How can I help you explore Laravel packages today?