Mobile Bottom Nav Laravel Package

Technical Evaluation

Architecture fit. This is a thin, stateless presentation-layer plugin for Filament panels. It reads the existing navigation registry at render time and injects a fixed bottom bar via a render hook (PanelsRenderHook::BODY_END by default). There are no migrations, tables, queues, jobs, caches, or external services, so there is no data lifecycle to own and no rollback ceremony beyond removing one line from a panel provider. The key architectural property for a TPM is derivation over duplication: navigation stays single-sourced in Filament, so new pages and permission-gated items appear (or disappear) in the bar automatically. The one exception is hideSidebarToggle(true), which is enabled by default and mutates the panel shell below 1024px by hiding Filament's own topbar hamburger. That is a cross-cutting UX change, not a local widget — treat it as a design decision requiring explicit sign-off, not an accepted default. Its safety interlock (only applied when the bar rendered and the More button is enabled) is well designed and materially reduces the risk of stranding users without a way into the sidebar.

Integration feasibility. High, and the effort is genuinely small: one Composer require plus one ->plugins([MobileBottomNav::make()]) line. There is no custom theme, no Tailwind @source registration, and no asset build step — CSS is inline. That is what makes rollout cheap, and it is also the main design tradeoff: the bar will not inherit our design tokens, brand palette, or spacing conventions without publishing and owning the Blade view. Configuration is fluent and optionally layered (fromNavigation(), items(), moreButton(), hideSidebarToggle(), renderHook()), and MobileBottomNavItem supports closures for labels, badges, active state, and visibility — which is the escape hatch that makes role-aware bars feasible without forking.

Technical risk. Moderate-low, but concentrated in a few identifiable places rather than spread evenly:

• Bus factor and battle-testing. Single primary author, ~20 stars, zero dependents. Recent contributions from two outside contributors and Dependabot activity indicate the project is alive, but this code has not been exercised at scale. Assume we are early adopters and budget for discovering edge cases ourselves.
• Auto-extraction semantics. The v1.3 fix is the cautionary tale: items were previously sorted globally by raw navigationSort, ignoring group membership, which could surface an unrelated page ahead of primary navigation. It now mirrors Filament's sidebar order. This is fixed, but it demonstrates that "just register the plugin" hides real ordering semantics in panels with navigation groups, clusters, or multi-tenancy.
• Version floor is our problem, not the package's. v1.4.1 deliberately dropped an enforced Filament floor, keeping ^4.0 || ^5.0, and instead recommends 4.11.5+/5.6.5+ because earlier 4.x/5.x releases carry published advisories — including an unauthenticated temporary file upload on auth pages. The plugin will happily install on a vulnerable Filament. Security posture is entirely a function of what we pin.
• Inline CSS means theming drift. A rebrand or dark-mode token change will need manual follow-up in this package's published view.
• Accessibility is unaddressed in the docs. No stated keyboard navigation, focus management, ARIA semantics, or minimum tap-target guarantees. Fixed bottom bars also interact badly with on-screen keyboards and mobile browser chrome. Verify empirically before shipping to field users.
• Render-hook collision. BODY_END is a shared hook; other packages or custom Blade may compete for it, and z-index/overlap with toasts, modals, or cookie banners is a plausible source of visual defects.

Key questions a TPM should get answered before committing engineering time:

1. Which panel(s) and which user cohorts actually use mobile? If mobile traffic is a rounding error, this is polish, not a lever.
2. Do we accept the default hideSidebarToggle(true) panel-shell change, or opt out? Who owns that UX call?
3. What Filament patch level will we pin, and does composer audit gate our pipeline? The package will not protect us here.
4. Which navigation items are the right four? Auto-extraction gives a correct order but not a correct priority — the default 2 items + More is rarely the right answer for a real app.
5. What is our exit plan if the package is abandoned — publish the view and vendor it, or replace with a custom render hook?
6. Does badge closure evaluation introduce per-item queries on every panel render? Worth a query-count check on a hot page.
7. If we adopt, do we also evaluate the same author's filament-mobile-preset — or explicitly scope it out? The package README itself says it fixes navigation "and deliberately nothing else."

Integration Approach

Stack fit. Native to our stack if we run Filament v4/v5 panels; it installs as a standard Composer package with Laravel package auto-discovery and requires no Node toolchain, no Vite entry, and no published assets to function. It fits the "no build step" constraint that many internal admin panels operate under. Blast radius is one panel provider file, which means it can be scoped to a single panel — a pilot panel and a production panel can diverge for as long as we need.

Migration path. Additive and reversible in both directions. Rollout is a Composer require, a plugin registration, a deploy. Rollback is deleting the registration line and redeploying; no schema, no data, no user-generated content affected. Because the bar hides itself on desktop, desktop users are unaffected except where hideSidebarToggle applies. The only non-trivially reversible piece is the decision to keep the hidden hamburger — if that turns out to confuse users, we flip one flag rather than unwind an architecture.

Compatibility. Two axes need pinning separately. First, Filament major/minor: the constraint ^4.0 || ^5.0 is permissive by design, so we must set our own floor at 4.11.5+/5.6.5+ in the application's composer constraints and let composer audit fail the build on advisories. Second, our panel configuration surface: navigation groups, clusters, tenant-scoped panels, custom NavigationItem subclasses, and any resource using shouldRegisterNavigation(false) all affect what auto-extraction yields. Test against the messiest panel we have, not the cleanest. Also confirm behavior alongside any other package registering at BODY_END.

Sequencing. A four-step ramp keeps the risk contained:

1. Pilot on a low-stakes panel with default config. Instrument mobile-specific analytics (session counts, nav-item taps, More-button taps, task completion for the two or three mobile jobs that matter). Two weeks.
2. Decide the panel-shell question. Review hideSidebarToggle with design and support; capture the decision in the decision log either way.
3. Tune for intent. Move from auto-extraction to explicit items() with visible() role gates and badge closures for the pilot's real top tasks. Publish and own the Blade view only if theming diverges — otherwise stay on the upstream template to keep upgrade cost at zero.
4. Expand or stop. Gate broader rollout on measured improvement in mobile task completion or a defensible qualitative signal from field users. Treat filament-mobile-preset as a separate, later decision with its own evaluation.

Operational Impact

Maintenance. Low steady-state, but not zero. The package is a single-purpose view layer with a small surface, and its release cadence is patch-oriented — however, upgrades track Filament majors, and Filament majors move. Budget an owner and a recurring line item: a compatibility check on each Filament minor, plus a theming check on any design-system change. Because CSS is inline, our design system and this package can drift silently. The single-maintainer risk is real; mitigate by pinning to a known-good version, publishing the view into our repo if we customize it, and treating the whole thing as ~200 lines we could absorb in-house if upstream goes quiet.

Support. Two distinct support populations. End users will generate tickets of the "my navigation disappeared / I can't find the menu" shape, most likely from the hidden hamburger or from a panel where the bar failed to render. Pre-empt with a short internal note and a support-macro. Developers need to know that navigation ordering now depends on group-then-sort semantics — document that, because the v1.3 bug is exactly the class of confusion that reappears as a "why is this page first?" ticket. Also flag the accessibility gap: if we have any accessibility commitment, verify and remediate before rollout rather than after a complaint.

Scaling. Scales trivially in the technical sense — no server-side cost, no persistence, no cross-request coupling, and the rendering work is bounded by the number of slots. Two scaling caveats are worth naming. Badge and label closures execute per render; if those closures hit the database (unread counts, queue depth), a bar on every mobile page view multiplies that cost across the busiest surface in the app. Audit query counts on a representative page before wide rollout. Second, adoption scaling is a governance problem, not a technical one: if multiple teams own multiple panels, someone must own the shared convention for slot selection, otherwise every panel invents its own four items and the "consistent mobile shell" benefit evaporates.

Failure modes. Ranked by likelihood and cost:

• Bar renders but sidebar is unreachable. Highest severity. The hideSidebarToggle interlock prevents the obvious version of this, but a custom renderHook(), a competing BODY_END element, or a moreButton(false) combined with the default hide would strand users. Configure both flags together, always.
• Overlap or occlusion with toasts, modals, cookie banners, or chat widgets at the bottom of the viewport; safe-area insets cover notched devices but not third-party overlays.
• On-screen keyboard interactions — a fixed bottom bar on a form-heavy page can cover the focused input or the submit button. Test the actual data-entry flows, not just the dashboard.
• Silent theming drift after a rebrand or dark-mode token change.
• Upstream abandonment — no security patches, no Filament v6 support. Low probability in the near term given recent activity; low cost given the exit plan.
• Vulnerable Filament baseline — the package will not stop us running a version with known advisories. This is our pipeline's job.

Ramp-up. Near-zero for engineers: registration is a one-liner and the fluent API is self-documenting. The real ramp-up is organizational. Design needs one review cycle to rule on the hidden hamburger and the bottom-bar safe area. Support needs a briefing and two macros. Analytics needs a mobile-segmented view of the panel so the pilot produces a decision rather than an anecdote. Product needs a stated hypothesis — e.g. "mobile admin task completion rises for the field cohort within two weeks" — because the package is cheap enough to install on enthusiasm alone, and the failure mode for cheap wins is that they ship without a metric and nobody can say afterward whether they helped. Total realistic time to a defensible go/no-go: two to three weeks, dominated by observation rather than implementation.