Uri Util Laravel Package

Product Decisions This Supports

• Build vs. buy (make vs. adopt): Answers the recurring question "do we write our own URL/URI parser?" The answer is almost always no — URI handling is a well-specified but deceptively bug-prone domain (percent-encoding, reserved vs. unreserved characters, dot-segment removal, relative reference resolution). This package is a narrow, single-purpose utility that removes that work from your backlog.
• Feature enablement: Directly supports any roadmap item that touches URLs — API client construction, webhook target management, link canonicalization for caches and deduplication, redirect chains, pagination and filter query-string assembly, subdomain/tenant routing checks, and sitemap or crawler tooling.
• Security posture decisions: Canonicalization and resolution are the primitives behind open-redirect protection, SSRF target allow-listing, and cache-poisoning defenses. Choosing a vetted normalization routine is a security decision, not just a coding convenience — but see the adoption caveat below.
• Ecosystem alignment: If your stack already includes Spomky-maintained components (JWT framework, WebAuthn libraries), adopting this keeps URI semantics consistent across those integrations and reduces the number of competing URI models in one codebase.
• Test infrastructure: Useful for generating URI fixtures and asserting normalization behavior in test suites without pulling in a full HTTP stack.

When to Consider This Package

Consider it when:

• You are in PHP and need RFC 3986-style parsing, resolution, or normalization as a utility, not a full HTTP abstraction.
• You want a small, dependency-light library with no PSR-7/PSR-17 coupling — you just need strings in, strings out.
• You are already inside the Spomky ecosystem and value consistency over independent vendor selection.
• You are prototyping or working in an internal tool where the blast radius of a dependency swap is small.

Look elsewhere when:

• Adoption signal matters. Zero dependents and a zero score mean this is effectively an internal/companion library for its author's other projects. It has not been battle-tested by an external community. For anything load-bearing, prefer league/uri (broad adoption, active maintenance, URI templates, IDN/IRI support) or guzzlehttp/psr7 / nyholm/psr7 if you need PSR-7/PSR-17 compliance.
• You need RFC 6570 URI templates, IRI/IDN handling, or WHATWG-style browser URL semantics — league/uri covers these; this package likely does not.
• You need vendor support, security review artifacts, SLAs, or a published release cadence.
• You are outside PHP, or you need a full request/response object model rather than string utilities.

If you do adopt it: pin the exact version, read the (small) source before relying on it, and wrap it behind your own thin interface so swapping to league/uri later is a one-file change.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source utility that handles URL parsing and normalization so our engineers don't hand-roll it. Hand-rolled URL logic is a known source of security bugs (redirect hijacking, cache poisoning, request forgery) and quiet data bugs (duplicate records that differ only by encoding). Adopting a library here is cheap hygiene, not a platform bet — integration cost is measured in hours, and it removes a class of defects from our roadmap.

To engineering leadership: Single-purpose PHP library for URI manipulation, maintained by an established PHP author (Spomky) whose other work we may already depend on. Trade-off to be explicit about: it has no meaningful external adoption — zero dependents, no community footprint — so it should be treated as unvetted third-party code rather than a strategic dependency. Recommended posture: adopt behind an internal adapter with a pinned version, and keep league/uri as the designated fallback if requirements grow (URI templates, IDN) or if the package goes stale. Do not let it become load-bearing without a second look.

Bottom line: Low cost, low risk if scoped narrowly and wrapped. The decision worth escalating is not "should we use this package" but "should any URL handling be bespoke" — and the answer to that is no.