- What does innmind/url-resolver actually do?
- The package converts URLs into their canonical, absolute form and, when enabled, follows HTTP redirects to the final destination. It resolves relative references against a base address, copes with mixed encodings, and returns the final URL together with the full hop history. It is framework-agnostic, so it targets any PHP code that needs one consistent URL rather than a framework router. Some descriptions also call it a URL-to-handler resolver, so read the source to confirm which capability you are getting before adopting it.
- Does innmind/url-resolver work with Laravel?
- It can be installed as a plain Composer dependency, but it ships no service provider or facade, so you would register and bind it yourself in the container. For typical Laravel work, url(), URL::to(), route(), and the HTTP client already produce absolute URLs and follow redirects. The package only adds value when you specifically need the hop history or a transport-agnostic abstraction, and the archived status makes any Laravel 10, 11, or 12 compatibility claim untested.
- Which PHP and Laravel versions does innmind/url-resolver support?
- Version 5.1.0 requires PHP 8.2 or newer because it dropped PHP 8.1 support, so any app, CI image, or shared host still on 8.1 fails at composer update time. There is no declared Laravel version constraint because the library does not integrate with the framework. Given the repository is archived, treat compatibility with current Laravel releases as unverified and test it yourself.
- Why does composer require fail with an innmind/immutable conflict?
- Version 5.1.0 requires innmind/immutable ^5, so any transitive dependency that still pins ^4 makes the dependency solver fail. In a large Laravel dependency tree this is the most likely installation blocker. Run composer why-not innmind/immutable 5 to identify the conflicting package before investing more time.
- Is innmind/url-resolver still maintained?
- No. The repository is archived with two stars, zero dependents, and no release since 2023-09-16. An archived package receives no security fixes, no PHP compatibility updates, and no bug fixes, so adopting it means owning it internally the moment something breaks. Check whether the Innmind maintainer consolidated the code into a successor package before deciding to fork.
- How do I get the full redirect chain from a URL?
- Enable redirect following when resolving, and the result returns the final URL plus the complete hop history instead of just the last response. That lets downstream code receive one canonical destination while still auditing each intermediate hop. Depth is bounded by the configurable redirect limit, so loops and runaway chains fail predictably.
- Can I limit redirect depth or restrict allowed URL schemes?
- Yes. The package exposes configurable limits on maximum redirect depth and on the set of allowed schemes. You can therefore reject non-HTTP schemes and stop chains that exceed your policy before they reach downstream code. Because the limits apply per resolution, you can keep stricter profiles for user-submitted links and looser ones for crawling.
- Can I replace the HTTP client for testing?
- The HTTP client is pluggable, so a custom transport or a fake can be swapped in for tests. That keeps redirect-following behaviour testable without network calls. In a Laravel app, wrapping the package behind a small adapter makes it easier to inject Laravel's HTTP client today and to replace the dependency later.
- Is the result object immutable and PSR-friendly?
- The overview describes the result objects as PSR-friendly and immutable, so the returned URL and hop history can be shared without defensive copying. Treat that claim cautiously: the package is archived, and its public API may expose innmind/immutable types, which would leak that dependency into your own signatures. Read the source to confirm whether those types are internal or part of the contract.
- What are the alternatives to innmind/url-resolver in a Laravel app?
- For Laravel applications the native tools usually suffice: url() and URL::to() for absolute URL generation, route() for named routes, and the HTTP client or Guzzle for redirect following with history. If you need stricter RFC 3986 parsing and normalisation, league/uri is actively maintained and widely used. Adopt innmind/url-resolver only if you truly need its framework-agnostic behaviour and accept maintaining a fork.