Basepath Laravel Package

Technical Evaluation

Architecture fit: Poor-to-moderate for a Laravel-primary stack. Laravel's HTTP layer is Symfony HttpFoundation (Illuminate\Http\Request extends Symfony\Component\HttpFoundation\Request), which already exposes getBasePath(), getBaseUrl(), and getSchemeAndHttpHost(), with url(), asset(), route(), and TrustProxies layered on top. selective/basepath is a PSR-7 utility purpose-built for Slim 4's request/middleware pipeline. There is no natural insertion point in a Laravel request lifecycle — it solves a problem Laravel has already solved, in a request representation Laravel does not use.

Integration feasibility: Technically feasible in an afternoon; not advisable. You would construct a PSR-7 request (via nyholm/psr7 or guzzlehttp/psr7), run BasePathDetector, then push the result back into Laravel via URL::forceRootUrl(), a config value, or a request attribute. That is a two-way format conversion on every request to obtain a value Symfony computes natively from SCRIPT_NAME/REQUEST_URI. Only justified if the identical detection logic must be shared with non-Laravel services.

Technical risk: Low in absolute terms — small surface area, pure PHP, no native extensions, MIT. The risks are relational rather than technical: 48 stars and 0 dependents means almost no independent production validation; the opportunity score (37.85) signals a low-attention niche; the 2026-02-05 release should be reconciled against the actual Packagist tag and PHP constraint before pinning. The library's core assumptions about SCRIPT_NAME/REQUEST_URI parsing may not match the header semantics your edge (ALB, nginx, Cloudflare) actually emits.

Key questions:

• Is there any non-Laravel (Slim) service in the estate that would consume the same base-path logic? If no, the dependency buys nothing.
• Are we deployed under a subdirectory, or at a domain root behind a proxy that rewrites SCRIPT_NAME? The former is this package's problem domain; the latter is a TrustProxies/forceRootUrl problem.
• What is the maintainer's issue-response and release cadence? Assess bus factor before code-level fit.
• Can we vendor ~200 lines of equivalent logic, or write a 30-line resolver over getBasePath(), instead of adding a dependency?

Integration Approach

Stack fit: Poor for a Laravel monolith; moderate for polyglot estates where a Slim 4 service is mounted at /api or /svc alongside a Laravel app and both must agree on base path. If Laravel is the sole consumer, treat this as a reference implementation to copy, not a Composer requirement.

Migration path: If adopted for a mixed deployment, consume it behind an interface (BasePathResolver) with two implementations: a native Symfony one using Request::getBasePath(), and a PSR-7 one using selective/basepath. Bind via the container; keep the package out of domain code. The change is additive — no schema, no data migration, no queue impact.

Compatibility: Verify the PHP constraint against your runtime (8.2/8.3/8.4) and PSR-7 implementation parity (nyholm/psr7, guzzlehttp/psr7). Laravel 10/11/12 pin Symfony HttpFoundation 6.x/7.x — confirm no transitive conflict, though a package this small should be framework-agnostic. Watch for psr/http-message v1 vs v2 splits, a common failure point in single-maintainer libraries.

Sequencing:

1. Confirm deployment topology: subdirectory mount vs. proxy rewrite vs. domain root.
2. Prove the native path fails — i.e., getBasePath() returns empty where it should not — before adding any dependency.
3. If a PSR-7 boundary already exists (Octane middleware, an API gateway layer), insert detection there; otherwise resolve once at URL::forceRootUrl() in a service provider.
4. Only if a Slim service shares the requirement, add the package and extract the shared interface.

Operational Impact

Maintenance: Near-zero runtime footprint — no migrations, no config publishing, no cache, no scheduled work. Maintenance is dependency-surface only: one Composer entry, one lockfile diff, one PHP constraint to track. The real cost is the PSR-7↔HttpFoundation adapter you own indefinitely, which will be more code than the value it transports.

Support: Single-maintainer project in the Slim ecosystem; 48 stars and 0 dependents implies limited external bug surfacing. Plan to self-support. MIT removes legal and compliance friction entirely.

Scaling: Irrelevant to throughput — detection is a handful of string operations per request, dwarfed by autoloading. No shared state, so horizontal scaling is safe. Under Octane, ensure any cached base path is recomputed per request or is provably invariant, so a long-lived worker cannot leak a path across hosts or tenants.

Failure modes:

• Incorrect base path → malformed absolute URLs in redirects, asset paths, signed URLs, and password-reset links; typically surfaces only in subdirectory or proxied environments, i.e., late and in production.
• Double-handling: both this package and forceRootUrl() set the root, producing /app/app/... paths.
• Proxy header mismatch: X-Forwarded-Prefix stripped at the load balancer, detection silently falls back to /.
• Version drift: PSR-7 interface majors, or a PHP constraint that blocks the next Laravel upgrade.
• Octane staleness: a detected prefix cached across requests in multi-tenant or multi-host deployments.

Ramp-up: Hours, not days — the API is a detector plus middleware. The learning cost sits in the deployment topology and in the adapter you write. Concentration risk is documentation: if the rationale is not recorded, a future maintainer will remove the dependency and reintroduce the bug it was masking.

Recommendation: Adopt as a pattern/reference, not a dependency, for a Laravel-primary stack. Revisit only if Slim 4 services remain in the estate and base-path logic must be shared across frameworks.