Templated Uri Bundle Laravel Package

Technical Evaluation

Architecture fit — poor for a Laravel stack, by construction. ibexa/templated-uri-bundle is a Symfony bundle, not a framework-agnostic library. Its entire surface area is Symfony-specific: a HautelookTemplatedUriBundle registered in AppKernel/bundles.php, a DI extension (HautelookTemplatedUriExtension), a compiler pass (TemplatedRouterPass), and a container alias hautelook.router.template. Laravel has no bundle/kernel/compiler-pass concept, so the bundle layer delivers zero value in a Laravel application. The genuinely useful part — RFC 6570 URI template expansion — lives in the upstream hautelook/TemplatedUriRouter library, which the bundle merely wires up.

The problem is that the underlying library is itself Symfony-flavoured: it ships a Symfony router and URL generator built on Symfony\Component\Routing. Laravel's Illuminate\Routing was historically forked from Symfony Routing but has diverged; you should not assume interface compatibility for UrlGeneratorInterface, RequestContext, or route collection semantics in current Laravel versions. So the realistic architecture is: adopt the RFC 6570 concept, not this package.

Integration feasibility — low as-is, moderate via a substitute. There is no supported path to composer require ibexa/templated-uri-bundle in a Laravel app and have it do anything. Two viable paths exist:

1. Pull only the upstream library and write a Laravel service provider that binds it as a singleton. This still drags in symfony/routing alongside illuminate/routing, which is a dependency-hygiene problem and a version-constraint collision risk.
2. Use a native, framework-neutral RFC 6570 implementation — guzzlehttp/uri-template (RFC 6570 levels 1–4, PHP 8 compatible, widely used) or rize/uri-template. Then expose it through a thin UriTemplate facade/service and a Link: header or HATEOAS response helper. This is the recommendation; it delivers the same product capability with a dependency your team can actually support.

Technical risk.

Key questions for the team:

• Do we actually need RFC 6570 semantics ({?page,sort}, {+path}, {&filter*}, explode modifiers), or do we just need clean query-string building that http_build_query and URL::route() already solve?
• Who is the consumer of the templated links — our own SPA, a third-party integrator, or a spec (JSON:API, HAL, OpenAPI links)? If the answer is "our own SPA," the templating benefit is marginal.
• Is there an Ibexa DXP system anywhere in the estate? If not, the fork's raison d'être does not apply to us.
• Is the team willing to own a ~150-line Laravel adapter indefinitely? If not, the package is disqualified regardless of technical merit.
• Does our API contract mandate templated links in responses, or is this an internal convenience?

Integration Approach

Stack fit. Assume Laravel 10–12, PHP 8.1+. The correct mapping is:

• hautelook.router.template service → a UriTemplateServiceProvider singleton binding, or a UriTemplate facade.
• Symfony DI extension / compiler pass → config/uri-template.php plus a service provider register() method.
• Symfony router decoration → not applicable; keep Laravel's router untouched and expose templating as a link generation concern only, not a routing concern. This is an important scoping decision: templated URIs are for responses, not for inbound dispatch.

Migration path. There is no migration from Symfony to Laravel here; the meaningful migration is from hand-concatenated query strings to templated links:

1. Inventory every place the codebase builds query strings by concatenation or http_build_query and emits them into API responses, pagination envelopes, or Link headers.
2. Pick one response shape (e.g., a paginated collection) as the pilot.
3. Introduce a single UriTemplate::expand(string $template, array $vars): string boundary and route all emissions through it.
4. Retire the ad-hoc string building incrementally; do not attempt a big-bang sweep.

Compatibility. Version-pin whatever engine you choose and add a contract test that asserts expansion output against the RFC 6570 examples table for levels 1–4. That test is what protects you from a silent upstream change, and it is cheap. Do not depend on the bundle's Symfony service definitions in any form; if you evaluate the upstream library directly, wrap it so the Symfony types never leak past the adapter — that keeps the escape hatch to guzzlehttp/uri-template open at roughly one file's worth of change.

Sequencing. Week 1: decide need (do the key questions above have "yes" answers?) and spike the adapter against the RFC example table. Week 2: pilot on one endpoint plus the Link header helper, with tests. Week 3+: broaden to pagination/filtering envelopes, then document the template conventions in the API style guide so consumers and producers agree on operator usage.

Operational Impact

Maintenance. The bundle itself would be near-zero maintenance if it worked on our stack — but it does not, so the maintenance burden transfers entirely to our adapter. That adapter is small but permanent, and it sits on a dependency (the upstream router) that is maintained by Ibexa for Ibexa's roadmap, not for ours. The honest framing to stakeholders: "this is not a dependency we adopt, it is an approach we implement, and the implementation is ours to keep." Choosing guzzlehttp/uri-template materially reduces that burden because it has a broad install base and active security response.

Support. With 3 stars and 0 dependents, there is no community support surface: no Stack Overflow corpus, no third-party tutorials, no issue triage for our edge cases. Escalation path is "read the source." For a TPM this matters less for correctness (the RFC is public and the algorithm is simple) and more for schedule risk: every unexpected behaviour becomes an internal research task rather than a search-and-fix.

Scaling. Expansion is pure string manipulation — microseconds per call, no I/O, no allocation of note. It will never be the bottleneck. The only scaling concern is indirect: if templated links are generated inside serialization of large collections, precompute per-request templates (the template shape is stable per endpoint; only variables change) and expand against cached strings. Cache the template string in config, not the expansion.

Failure modes to design against.

• Malformed template throws at render time — in an API response path this becomes a 500 on an otherwise healthy request. Wrap expansion and decide explicitly: fail loud in dev, degrade to a non-templated URL in production.
• Encoding mismatch — RFC 6570's operator semantics (+, #, &, *) interact badly with naive urlencode calls applied on top of expansion. Double-encoding and reserved-character loss are the most likely real-world bug. Covered by the RFC conformance test.
• Un-escaped braces leaking to clients — a template emitted without expansion looks like a bug to consumers and breaks link following. Assert in the response test suite that no { appears in emitted href/Link values.
• Template injection — if a user-supplied string reaches the template position, an attacker can inject operators and reshape the URL (open-redirect-adjacent, cache-poisoning-adjacent). Enforce at the type level: template is a constant, variables are data.
• Dependency drift — a future Laravel or PHP minor bump breaking a Symfony-routing-coupled library. Mitigated by the adapter boundary and the pin.

Ramp-up. Low for the concept, low for the code. An engineer who knows Laravel can implement the adapter in under a day and add meaningful tests in another. The real ramp-up cost is organisational: getting API producers and consumers to agree on which template operators are permitted and what the expanded links look like. Budget half a day for a style-guide decision and treat it as the gating deliverable — without it, different endpoints will emit subtly different template dialects and the standardisation benefit evaporates.

Bottom line for planning: score this package as low fit for a Laravel roadmap — the bundle is unusable and the upstream library is a poor dependency choice. The capability it advertises (RFC 6570 templated links for HATEOAS-style APIs) is worth evaluating, but through a native engine behind a one-file adapter, gated on a clear answer to "who consumes these templated links and does our contract require them?" If that answer is not crisp, defer: URL::route() plus http_build_query covers 90% of the value at 0% of the dependency cost.