Laravel Browser Filter Laravel Package

Product Decisions This Supports

• Legacy-browser gating on specific routes. The package lets you declare, at the route level, which browser families/versions may pass — so you can redirect IE≤10 users away from a checkout or dashboard to an upgrade page instead of shipping polyfills and fallback CSS into the main bundle. That is a real, if narrow, product lever: it converts "support every browser" into an explicit, priced support contract.
• Sunsetting decisions with a deadline attached. A declarative support matrix makes the "when do we drop browser X?" conversation concrete and reversible. Turning off a route rule is a one-line change, which is exactly what you want when the answer is "let's try it and watch support tickets."
• Reduced / degraded experience as a first-class route. Serving a "lite" experience at a separate URL for old user agents isolates legacy code paths from the main controller and template tree — useful if you want to measure whether legacy users convert at all before investing in them.
• Security or compliance carve-outs. Blocking known-unsupported user agents from auth/payment routes is occasionally a compliance ask (PCI-adjacent, or internal infosec standards). Cheap to satisfy with middleware.
• Roadmap scoping. The package's scope is a useful boundary marker: it does server-side user-agent string matching and nothing else. It gives you no client hints (Sec-CH-UA), no feature detection, no analytics on browser mix, no bot detection. Any real "browser support strategy" initiative is 10x this surface area — don't let a middleware package stand in for the strategy.

When to Consider This Package

Consider it only if all of these hold:

• You are on Laravel 5.5–5.7 / PHP 7.1-era. The last release is April 2018; assume no compatibility with Laravel 8+, PHP 8+, or modern middleware priority/serialization changes without a fork.
• Your requirement is genuinely just "filter routes by UA family and version" — no feature detection, no client hints.
• You are willing to vendor or fork it. Treat it as source you adopt, not a dependency you install.
• You accept the maintenance and security-review burden yourself. 20 stars, one release six years ago, and a low opportunity score mean no upstream triage for UA-parsing edge cases or CVEs.

Look elsewhere (or build) if:

• You need UA parsing you can trust. Build ~40 lines of middleware around a maintained parser — mobiledetect/mobiledetectlib, browscap/browscap-php, or whichbrowser/parser — and keep this package's clean route-declared constraint syntax as the design you copy. That's a one-day build and it wins on maintenance, security posture, and framework currency.
• You need client hints (Sec-CH-UA, Sec-CH-UA-Platform) — the modern replacement for UA sniffing, unsupported here.
• You need feature detection rather than browser identification. Detect at the client (Modernizr-style, or just @supports) and send a capability flag; server-side UA matching is a proxy for the real question and always drifts.
• You need bot or fraud filtering. UA matching is trivially spoofable; this is not a security control.
• You need data on browser mix before deciding. Ship client-side analytics first; buy the evidence, then decide whether any server-side gating is warranted at all.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose utility that lets us block or redirect specific browsers on specific pages. The idea is sound and cheap to replicate; the package itself is not a dependency worth betting on. It hasn't shipped a release since 2018, has negligible adoption, and won't run on a current Laravel stack. Recommendation: do not adopt. If the legacy-browser requirement is real, we implement the same pattern in-house in about a day, on a maintained browser-detection library, and we own it.

To engineering: Mine it for design, not code. The valuable part is the ergonomics: browser constraints declared alongside the route, enforced by one middleware, so support policy lives in the route file rather than scattered through controllers. Reimplement that against mobiledetect or whichbrowser, add tests for the UA strings we actually see in logs, and treat the resulting policy as configuration — not as a security boundary, since UA strings are client-controlled. Budget: roughly one engineer-day plus test coverage. The alternative — forking a six-year-old package — costs more over the next two years than writing it fresh.

Framing for the build-vs-buy call: the package scores 0.38 on opportunity and 0.46 overall, with a 2018 last release. It is a reference implementation, not a vendor. The correct output of evaluating it is a design decision ("we want route-level browser policy") plus a small first-party build — not a composer require.