Filament Collapsible Subnav Laravel Package

Technical Evaluation

Architecture fit. This is a purpose-built Filament plugin and nothing else. If the admin panel is on Filament v3/v4/v5, it slots into the existing Panel configuration with no new infrastructure, no service to operate, no data model, no auth or routing changes. It is a presentation-layer concern — collapsing a secondary sidebar inside resource pages. That narrow scope is its strongest TPM-relevant property: small blast radius, trivially revertable, no cross-team coordination.

Integration feasibility. composer require is genuinely the entire setup. No publish, no config file, no manual provider. Optional theme build for request hygiene. Realistic integration effort is a half-day including pilot, smoke test, and review — assuming the panel is already Filament and at least one resource uses SubNavigationPosition::Start.

Technical risk.

• Provenance: 10 stars, 0 dependents, single maintainer (a Mexico-based consultancy), no commercial support tier, no SLA. There is no evidence of this package operating at scale in the wild.
• Coupled to Filament internals: The plugin's behavior depends on Filament's internal CSS class names and DOM structure. v4 renamed .fi-sidebar-item-button → .fi-sidebar-item-btn; v1.6.0 exists primarily to patch the resulting silent breakage of tooltips. This is the dominant long-term risk.
• Anti-FOUC mechanism is fragile to infrastructure: an inline <head> script marked data-cfasync="false" to survive Cloudflare Rocket Loader. CDNs, HTML minifiers, and edge workers can strip that attribute and quietly reintroduce flicker.
• Auto-registration is a governance concern: composer require modifies every panel without a reviewable diff. Convenient for a prototype; unacceptable as a default on a shared codebase.
• Fork cost is low: the package is small (per the dev assessment, the two non-obvious files are the head-injection and the SPA re-sync listener). This is what makes the dependency defensible at all.

Key questions.

1. Do we actually have a resource page where sub-nav is eating content width — or is this a solution in search of a problem? Typical trigger is 6+ tabs on a 1280–1440px screen.
2. What is the measurable outcome? Reduced tab hunting, faster time-to-complete on the page's primary task, or just aesthetic preference?
3. Who is the named internal owner for Filament upgrade re-verification?
4. Do we adopt explicit per-panel registration (recommended) or accept auto-registration globally?
5. Does our production path (CDN, minifier, CSP) preserve the anti-FOUC script and permit inline styles?
6. Could this be upstreamed to Filament rather than carried as a dependency?
7. What is the internal alternative — a ~50-line CSS/JS snippet vs. this package — and is the delta (SPA re-sync, server-rendered cookie state) worth the dependency?

Integration Approach

Stack fit. Enabling only if the panel is Filament v3/v4/v5 on PHP 8.1+ / Laravel 10–13. The compatibility matrix is unusually broad for a package this small, which reduces (but does not eliminate) version-negotiation cost during Laravel/PHP upgrades. If the admin stack is anything other than Filament, the assessment ends here.

Migration path. Zero-config is available, but take the explicit route: register CollapsibleSubnavPlugin::make() on specific panels so the change appears as a reviewable, revertable diff rather than a silent global side effect of a composer command. It also prevents the plugin from activating on panels where the UX hasn't been evaluated.

Compatibility and feature-flag lever. SubNavigationPosition::Start is the natural per-resource feature flag — resources using Start get the collapsible sidebar, everything else is untouched. That converts "should we enable the plugin" into the far more tractable "which pages get Start sub-nav," which is exactly the framing a TPM wants for a phased rollout. SPA mode (->spa()) is the strongest technical justification for taking the dependency: hand-rolled collapse code desyncs after the first livewire:navigated, and this package handles it.

Sequencing.

1. Pin ^1.6 explicitly in composer.json.
2. Register explicitly on one panel only.
3. Pilot on a single Start-sub-nav resource page with 6+ tabs.
4. Capture a baseline (tab click-through, time-to-complete for the page's top task).
5. Hold for two weeks; expand or revert based on signal rather than optics.

Operational Impact

Maintenance. This is a recurring cost, not a one-time integration. The plugin tracks Filament's internal DOM and class names, so every Filament major is a re-verification event, and some minors will silently break tooltips, badges, or padding without surfacing an error. The v1.5→v1.6 release is a concrete demonstration of the failure mode. Budget a few hours per Filament major plus a manual or CI smoke check whenever Filament is bumped.

Support. MIT, single maintainer, no commercial support, no community mass. We will be discovering edge cases for the maintainer, not the other way round. Mitigations: pin the version, designate an internal owner, and pre-approve fork-readiness — the code is small enough that forking is a realistic option if the project stalls.

Scaling. Runtime footprint is trivial: one inline CSS/JS block and one subnav_collapsed cookie per user. The scaling concern is surface area, not load: the more resource pages that adopt Start sub-nav, the more places a Filament upgrade can visually regress. Treat Start sub-nav as an intentional per-page decision, not a default, to keep that surface bounded.

Failure modes.

• Silent visual regression after a Filament minor bump — highest likelihood, low severity, high discoverability by end users.
• FOUC returning behind a CDN or minifier that strips data-cfasync="false".
• Tooltip styling inconsistent with a customized theme on v4/v5 (CSS ::after fallback vs. Tippy on v3).
• Auto-registration applying to panels it shouldn't — a governance failure, not a technical one.
• Maintainer abandonment — low near-term, medium over a 2–3 year horizon; mitigated by low fork cost.

Ramp-up. Effectively zero for developers — no API to learn, no mental model to carry. The real ramp-up cost sits with the assigned owner: knowing what to re-verify after a Filament upgrade and holding the line on the pilot-before-expand discipline.

Bottom line for the decision. Treat this as a time-boxed, single-page pilot rather than a platform-level commitment. The plugin doubles as a diagnostic: if nobody ever re-expands the sub-nav after two weeks, the finding is not "we need this toggle" — it is "the tabs are overloaded and the page should be restructured." Framed that way, the dependency is justified by the measurement it enables, not by the UI it ships.