Url Resolver Laravel Package

Product Decisions This Supports

• Build vs. buy for routing abstraction: The package offers a narrow, single-contract abstraction — URL in, responsible handler out. It supports the decision to buy/borrow a resolution pattern rather than maintain a bespoke router when your product routes outside Laravel's standard HTTP kernel (multi-tenant domain mapping, plugin/extension dispatch, webhook or job-handler routing, API gateway or edge dispatch).
• Decoupling routing from framework: Because it is framework-agnostic, PSR-request compatible, and requires implementing one resolver interface, it supports a roadmap decision to isolate routing concerns from Laravel so the same resolution logic can serve web, queue, CLI, and worker entry points — and be unit-tested without booting the framework.
• Feature enablement: The strongest product use cases are custom-domain → tenant → handler resolution, deep-link and canonical-URL handling, and "which callable owns this URL" dispatch in modular or plugin-based products. Standard CRUD routing on a single Laravel app gains little over Route:: — do not justify adoption on that basis.
• Roadmap timing and dependency governance: The package’s last release (5.1.0, Sept 2023) is a compatibility release that adds innmind/immutable v5 support and drops PHP 8.1 — not a feature release. Any adoption must be scheduled behind the PHP 8.2+ baseline migration, not alongside a product feature.
• Opportunity signal vs. adoption risk: The opportunity score (6.81) indicates a real, under-served problem space; 2 stars, 0 dependents, and an archived repository indicate the market has not validated this specific implementation. This supports using it as a reference design or vendored contract rather than a runtime dependency.
• Documentation inconsistency is itself a decision input: The repository description ("resolve relative URLs to absolute ones") does not match the package’s own description ("URL → handler resolution"). Resolve the ambiguity in a discovery spike before any decision; it changes the use case entirely (URL normalization vs. routing dispatch).
• Licensing: MIT permits forking and internal vendoring, which materially lowers the cost of the archived status — a copy-and-own path is available if the contract proves useful.

When to Consider This Package

• Consider adopting when the requirement is precisely a minimal URL → handler contract, the team is on PHP 8.2+, and you are already aligned on innmind/immutable v5.
• Consider adopting in non-Laravel entry points — workers, CLI commands, gateways, or plugin hosts — where Laravel’s router is not the natural dispatcher.
• Consider the pattern, not the dependency, when the architecture needs framework-free routing but long-term maintenance matters. Fork or reimplement the resolver interface in-house (MIT makes this cheap) and drop the external dependency risk.
• Defer or look elsewhere when standard Laravel routing satisfies the requirement. This package does not replace Route:: for conventional HTTP routing and adds a dependency for no differentiated value.
• Look elsewhere when you need active maintenance, security patching, community support, or an upgrade SLA. An archived repository with zero dependents and no releases since September 2023 fails any procurement or supportability bar for a production-critical path.
• Look elsewhere if the application is on PHP 8.1 and cannot move — 5.1.0 is a hard resolver failure on that runtime, and there is no evidence of a maintained 8.1 line.
• Before any rollout, validate: the actual innmind/immutable constraint (hard ^5 vs. ^4 || ^5), whether immutable types leak into public signatures, the Laravel major support matrix, and Composer resolution against your existing dependency graph.
• Treat as a spike, not a commitment, until the use case is confirmed and a fallback (fork/vendor) is decided.

How to Pitch It (Stakeholders)

• Executives: This is a small, MIT-licensed, framework-agnostic routing abstraction that could simplify how we map incoming URLs to handlers across web, queue, and worker entry points. However, the project is archived, has effectively no adoption, and has not shipped since September 2023. Recommendation: do not add it as a production dependency. Approve a short evaluation spike to capture the pattern internally (or vendor the contract), which costs days rather than committing us to an unmaintained package. No product scope expands either way.
• Engineering: The value is the URL → handler resolver contract, not the library. It decouples routing from Laravel, is testable without the framework, and works cleanly with PSR requests. The constraints are real: PHP 8.2+ required, innmind/immutable v5 required, archived upstream, and inconsistent documentation about what the package actually does. Recommended path: validate the contract in a one-sprint spike; if it fits, implement the interface in-house or vendor it under MIT; if not, close the ticket. Do not adopt it on a critical routing path without an owner for the fork.
• Product: There are no user-facing changes and no roadmap commitment implied. The decision is whether to invest a small amount of engineering time in a reusable routing abstraction that improves portability and testability, knowing the upstream project is unmaintained. Frame it as technical hygiene with an explicit "we own it if we use it" condition, and place it behind the PHP 8.2 baseline work — never in front of a feature commitment.