Device View Laravel Package

Product Decisions This Supports

• Responsive vs. device-specific delivery — the one real decision on the table. This package exists to enable dynamic serving: one URL, one route, one controller, different Blade markup per device class (mobile / tablet / desktop). That is an architectural fork, and adopting the package is a way of committing to it. Force the trade-off into the open: responsive CSS is cheaper to build, cheaper to cache, better for SEO, and simpler to QA. Per-device templates buy you something responsive cannot — a genuinely reduced mobile experience (fewer modules, lighter JS, different navigation, a mobile-lite checkout) — without forking routes or spraying if ($mobile) branches through controllers. Every other decision below is downstream of this one.
• "Mobile-lite" scoping for near-term roadmap items. If the roadmap wants a cut-down mobile experience but a full redesign is two or more quarters out, device-aware view resolution is a legitimate tactical lever: ship home.mobile with the three revenue-critical modules and leave desktop untouched. Present it as scope relief that buys time, not a platform bet — and put an expiry date on it in the roadmap so it doesn't quietly become permanent architecture.
• Build vs. vendor vs. depend. The capability is thin: a view-finder hook plus a device classifier, roughly 100 lines for the resolution logic. The honest framing is build or vendor, don't depend. One engineer can replicate the fallback behind an internal DeviceViewResolver interface in a day or two. "Buy" only wins if the cost of ~100 lines exceeds the cost of auditing an unmaintained dependency — which, for most teams, it does not. Whatever you choose, record it; "just add the package" is the wrong default here.
• Vendor-risk and lifecycle decisions. At 0.0.x, 14 stars, zero dependents, a single maintainer, and a last release in January 2017 whose only content is "Support Laravel 5.4," this is a legacy-estate artifact, not a forward-looking dependency. It warrants a dependency-register entry with an exact pin and a named replacement date, and it should inform — not drive — framework-upgrade planning, because a caret constraint on 0.0.x will never float onto a modern Laravel.
• QA and localization investment — the real cost line. The package is free; the variants are not. Every affected page now has up to three template trees to maintain, translate, and regression-test. Adopting this is a decision to grow the QA surface 2–3x for those pages, and to accept that silent fallback to desktop means a missing variant surfaces as a design regression someone screenshots, not an exception someone gets paged on. Budget it explicitly and fund the audit tooling (a CI command that fails on unexpected variant gaps) as part of the same decision.
• Caching and SEO decisions that follow automatically. Same URL, divergent HTML requires Vary: User-Agent and a CDN cache key that includes the UA or the package's device cookie. If the product depends on aggressive full-page caching or a URL-keyed CDN, this package's value proposition shrinks and may go net-negative. Separately, separate mobile HTML has mobile-first-indexing consequences that need a named SEO owner's sign-off before launch, not after.
• Explicitly not a roadmap input for modern products. It adds no user-facing capability to a current codebase. It is not a differentiator, not a growth lever, and nothing should be sequenced around it.

When to Consider This Package

Consider it when:

• The target application is genuinely pinned to Laravel 5.4 (or a 5.x line with equivalent view-finder behavior) and is not being upgraded within the planning horizon. Manual provider registration in config/app.php and an exact pin are part of the deal.
• You already have, or intend to maintain, materially divergent template sets. The economics only work if mobile/tablet markup differs substantially from desktop. If the delta is a handful of CSS classes, responsive CSS wins outright and you should stop reading.
• The requirement is narrow: swap a view variant by device class, fall back to default when absent, no controller branching, no route duplication.
• You accept single-maintainer, effectively dormant upstream and are prepared to fork and self-maintain — which the BSD-2-Clause license permits, with the notice retained.
• You can pin the exact version (composer require "torann/device-view:0.0.4"). A caret constraint on a 0.0.x line is a pin in disguise — safe, but it also means the package will never tell you it has become dead weight, so the register entry must carry the replacement date.
• You have caching and SEO sign-off in hand, and you can prove the finder decoration works under php artisan config:cache before it reaches a release week. Packages of this vintage routinely call env() outside config/*.php and only break in cached production deploys.

Look elsewhere (or build it) when:

• The app is on Laravel 5.5+ or is upgrading soon. The capability is a small decorated view finder; write or vendor it and remove the upgrade-cadence risk entirely.
• Responsive CSS would satisfy the requirement. It usually does, and it avoids the tripled template tree, the CDN changes, and the mobile-first-indexing conversation.
• The product needs the device class to drive business logic — pricing, entitlement, feature gating. Tablet detection is fundamentally unreliable (modern iPadOS Safari reports a desktop UA; large phones, small laptops, and touch convertibles all misclassify), so device class must stay presentation-only. If you need it for logic, this is the wrong primitive.
• You already decorate view.finder for theming or multi-tenant template overrides. The finder is a shared extension point; two decorators interact in an order you did not choose, and you would be resolving that instead of shipping.
• The site depends on aggressive full-page caching keyed on URL, or you cannot get an explicit owner for SEO/content-parity sign-off on revenue pages.

How to Pitch It (Stakeholders)

For executives: This is a small, free, unmaintained package from 2017 that lets one Laravel application serve different page templates to phones, tablets, and desktops at the same URL. It supports exactly one product decision — whether to invest in a reduced mobile experience now rather than wait for a full redesign — and it buys that option cheaply in engineering time. What it is not is a platform investment or a differentiator: no user-visible capability arrives that responsive CSS couldn't also deliver. The cost structure is the part to hear clearly: the package is a day of integration, the variants are weeks of design, translation, QA, and ongoing drift risk, plus a caching and SEO review before launch. Because it is a single-maintainer dependency with a last release that only declared Laravel 5.4 support, the recommendation is to build or vendor the ~100 lines rather than depend on it, and if we do take it, to pin the exact version and put a replacement date in the dependency register.

For engineering: Treat it as a legacy artifact, not a dependency. The only part you will ever need to reimplement is the finder decoration: resolve a view name, suffix it by device class, check view()->exists(), fall back to desktop. Wrap it behind our own DeviceViewResolver interface on day one so no application code imports Torann\... and replacement is a one-file change. Start with a layout swap (layouts.app → layouts.app.mobile) rather than per-page variants; escalate page-by-page only where the module list genuinely diverges, so the QA multiplier stays bounded. Add middleware for Vary: User-Agent and for a "view full site" desktop override, since the package provides neither. Make silent fallback loud: log a warning when a non-desktop device hits a missing variant, and run a CI audit command that fails on unexpected gaps against an explicit desktop-only allow-list. Verify three things explicitly before rollout — that the finder still resolves under config:cache, that view composers registered against the base layout name actually fire on the variant, and that namespaced views and view()->first() behave. Test with explicit user agents per device class; the test client's default UA will silently resolve to desktop and your mobile tests will pass without ever exercising the path.