Accordion Laravel Package

Technical Evaluation

Architecture fit. This is a narrow Filament schema layout component — not a framework, not a service, not a data-layer concern. It ships no migrations, no routes, no jobs, no config surface worth governing. Its blast radius is confined to the admin render tree, which is exactly the profile we want from a third-party UI primitive. It composes inside Section, Grid, Tabs, and Fieldset, so it slots into the schema conventions we already use rather than introducing a parallel layout idiom. The important scoping caveat: the integration value is specifically inside a Filament schema, where collapse must cooperate with form state, validation, and theming. Outside that context — a marketing FAQ block — a native <details>/<summary> element is zero-dependency, keyboard-accessible, and strictly better. We should not let this package drift into general-purpose front-end usage.

Integration feasibility. High, and cheap. composer require lara-zeus/accordion:3.0.2 with an exact pin, then one verification step before wiring anything up: determine whether this is a registered Filament plugin or a pure component by checking vendor/lara-zeus/accordion/composer.json and grepping src/ for a Filament\Contracts\Plugin implementation. A layout component usually needs no registration, and registering one that isn't a plugin is a self-inflicted panel-provider bug. The realistic first use case is a long Resource form where daily-use fields sit above and metadata (SEO, publishing, internal notes) sits below — an afternoon of work that replaces what would otherwise be a bespoke Alpine build.

Technical risk. The risk here is not code quality; it is dependency durability. The signal set is thin: 11 stars, zero dependents, a single maintainer, and a single-vendor ecosystem. The package is already on its third major line, which tells us the API has churned before and will likely churn again — and critically, those majors track Filament's majors. That makes this a package we cannot adopt independently of our Filament version. If we are behind on Filament, we are behind here, and the remediation is an upgrade we did not plan. Secondary risks: the zeus-accordion-btn-* / zeus-accordion-container-* modifier suffixes are named but not enumerated in the release notes, so they are unconfirmed contract until we inspect rendered DOM; and accessibility ownership is undocumented — nothing in the release notes claims aria-expanded, aria-controls, or keyboard handling, so we must assume it is ours until verified. Against that, the exit cost is genuinely low, and that is the mitigation we should lean on rather than pretending the risk is absent.

Key questions to resolve before commitment.

• Which Filament major does 3.x target, and are we already on it? Answer this first; a mismatch invalidates the rest of the evaluation.
• Is there a Plugin implementation, or is this component-only?
• What are the actual fluent method names — collapsed(), open(false), or something else — and what does the canonical make() signature actually accept?
• Does open/closed state survive a Livewire re-render triggered by a live() or reactive() field inside a collapsed panel?
• Are aria-expanded / aria-controls and Enter/Space keyboard activation present in the rendered DOM?
• Do the -* modifier classes exist as documented, or only the two base classes?
• What is the maintainer's commit cadence and stated support horizon, and who internally owns the fallback if this goes quiet?

Integration Approach

Stack fit. Laravel, Filament, Livewire, Alpine — all already in the stack. This introduces no new runtime, no new build step, no new hosting concern. That is the entire argument for buy-over-build here: one commodity primitive, consumed under MIT, replacing hand-rolled toggle logic that has almost certainly diverged across settings panels, FAQ blocks, and filter surfaces.

Migration path. Inventory existing hand-rolled toggles first, then replace them through a single wrapper rather than sprinkling Accordion::make(...) across call sites. Something like Fields::metaSection($schema, $open) in one support class, so heading copy, icon choice, default open state, and future theming live in one file. Without that wrapper, we have simply traded three divergent hand-rolled toggles for nine divergent package usages — the same maintainability problem with an added dependency. Theming gets exactly one file, targeting only zeus-accordion-btn* and zeus-accordion-container*, never internal DOM descendants. Descendant selectors against vendor markup reintroduce the fork debt that 3.0.2 exists to eliminate.

Compatibility. Pin the exact patch, not a caret range. With this adoption profile, upgrades must be deliberate — composer update lara-zeus/accordion -W, visible in a diff — not something a transitive update performs silently. Keep Filament major bumps and accordion upgrades in separate commits so that a breakage tells us which change caused it. Scope our CSS overrides behind an app-level class so restyling does not leak into Filament surfaces we did not intend to touch.

Sequencing.

1. Install pinned in a branch; read resources/views/ and src/ directly — on a package this small, the Blade source is the documentation, and the README is a starting point, not a contract.
2. Pilot exactly one screen — a single long Resource form. Verify rendering, verify collapsed fields still save, verify state survives re-render.
3. Build the wrapper class and the single theming stylesheet.
4. Backfill the remaining identified usages through the wrapper.
5. Document the exit path in the same PR that adds the dependency.

No cross-cutting rollout before step 3 completes. Accessibility remediation, if the ARIA audit comes back negative, belongs in the wrapper — one place, not nine.

Operational Impact

Maintenance. Expected code churn is minimal; this is a stable UI primitive. The real maintenance question is abandonment, not bugs. Structural containment is the answer, and it is cheap to enforce: exactly one file references zeus-accordion-* selectors, and all construction routes through the wrapper. Do that and swapping in a native <details>/<summary> or an in-house Alpine toggle is an afternoon, not a sprint. Violate it and the replacement cost scales with every call site we allowed to import the package namespace directly.

Support. MIT, no SLA, no escalation path, community-grade responsiveness from a single maintainer. We should name an internal owner for this dependency in the same breath as adopting it, because there is no vendor to escalate to. Realistic posture: assume we will be reading vendor source to answer our own questions, and budget accordingly.

Scaling. Negligible on the performance axis — collapse is client-side Alpine state. The scaling concern is form architecture, not throughput. Collapsed fields are still mounted, still validated, and still submitted, so a 60-field form wrapped in accordions is still a 60-field form. And deep nesting is a trap: an accordion inside an accordion inside a tab is technically fine and experientially awful, because the user has to remember click history to navigate back. One level of collapse only. If we want two levels, the actual problem is field count, and the fix is a tab or a wizard step.

Failure modes to plan for.

• Invisible validation failure. A required field inside a collapsed section fires client-side validation on a field the user cannot see — "the form won't submit and I can't see why." Mitigation: only optional fields go in collapsed sections, or required-ness is conditional on something visibly present, or the section opens by default.
• State reset on re-render. Filament re-renders schemas frequently; a section the user opened may snap shut after a live() update. This is the exact combination that breaks and must be tested explicitly on any form with live() fields inside a collapsed panel.
• Silent restyle on a patch bump. The realistic regression is a patch changing panel appearance, which functional tests cannot see. Need one visual check — screenshot test or a manual checklist item — covering collapsed and expanded states.
• Accessibility regression. If ARIA and keyboard handling are absent, that is our liability, and it is cheapest to fix once in the wrapper.
• Filament major drift. A forced Filament upgrade cascading into an unplanned accordion major is the scenario most likely to consume unplanned capacity.

Testing and ramp-up. Functional tests assert the form saves regardless of collapse state — that is the property that matters and it is genuinely easy to cover. Ramp-up for the team is low: the debugging path is inspect the DOM for the zeus-accordion-btn Alpine attributes, then read or publish the vendor views, then check CSS specificity against Filament's opinionated utilities before assuming a hook is missing. On upgrade, diffing the vendor views is the entire changelog we need. Net recommendation: adopt, scoped to inside-Filament schema usage, with the wrapper and the pinned patch as non-negotiable preconditions.