Filament Sidebar Resize Laravel Package

Product Decisions This Supports

• Build vs. buy for admin chrome — decided in favor of "don't build." A resizable sidebar is the archetypal request that everyone wants and nobody wants to own: it's a small CSS/JS problem that has to be re-validated on every Filament upgrade. This package converts that request into composer require plus one plugin registration in the panel provider. The product decision is to not allocate sprint capacity to bespoke panel overrides, priced at roughly zero engineering days and reversible in an afternoon.

• Cheap, visible UX wins on the internal-tools roadmap. Admin panels are judged by the people who live in them eight hours a day. Sidebar width becomes a real friction point when navigation labels are long, resource names are nested, or the UI is localized into languages where translated labels overflow the default width. This is a low-risk polish-sprint line item that lets you demonstrate responsiveness to internal feedback with something users notice on first login.

• A triage signal for navigation information architecture. If you are accumulating complaints about truncated labels, clipped badges, or horizontal scrolling in the panel, that is evidence your navigation has outgrown the default sidebar — and possibly that your resource grouping and naming need a rethink. Adopting this package buys time and removes the visible symptom; it does not answer the underlying IA question, which still belongs on the roadmap.

• Dependency-posture calibration for micro-dependencies. With single-digit stars, zero dependents, and a single-maintainer release history, this is snippet-scale software, not infrastructure. The PM decision it informs is about posture rather than features: pin the exact version, treat it as forkable source, and keep it off the critical path. It should never become something you cannot replace in a day.

• Forcing a written position on two defaults you would otherwise inherit. A drag-handle resize control raises two product questions worth deciding explicitly: does the chosen width persist across sessions and devices, and is the grip keyboard-operable and labelled for assistive tech? Whatever the package does by default, your decision record should say what you require.

• Scoping a pilot rather than a rollout. Because the failure mode is visual and silent, this is a natural candidate for a feature-flagged pilot on one internal panel with a named owner, not a blanket enablement across every panel in the estate.

When to Consider This Package

Adopt when:

• You already run a Filament admin panel and the sidebar width is the specific, named pain point. Confirm the package targets your Filament major before committing — the project advertises Filament v5, so a v3/v4 estate needs a compatibility check, not an assumption.
• Your users are a known, internal audience — ops, support, back office, finance — who will tolerate a small third-party UI dependency in exchange for a better daily workspace.
• You want the improvement this sprint, and the alternative is a custom Blade/Livewire override your team would own and re-validate on every Filament release.
• You are comfortable treating the dependency as forkable source. The change surface is one resize grip and its styles; worst case you copy it in-house, which is a bounded ~1 day task.
• You can run it behind a flag or on a non-critical panel while you build confidence.

Look elsewhere — or build it yourself — when:

• You are not on Filament, or you are on a major version the package does not target. Do not contort an upgrade plan around a UI nicety.
• You need guarantees: an SLA, a documented security-response process, or a dependency that survives a procurement or security audit. Zero dependents plus a single maintainer means you are the maintainer of last resort.
• Per-user persistence is a hard requirement and you cannot verify it. A resize that resets on every page load reads as broken and will generate more complaints than it resolves. Note also that browser-local persistence does not follow a user across devices — set that expectation or own a server-side preference.
• Accessibility is a compliance matter for your organisation. A pointer-only drag grip may not meet your standard; plan for keyboard equivalents and verify before rollout. The shipped v1.0.1 fix — a central grip to restore scrollbar access — is direct evidence that this affordance is genuinely fiddly to get right.
• Your real problem is navigation IA — too many resources, poor grouping, over-long labels. Resizing the container hides the symptom without fixing the structure.
• You are standardising on a design system or theme layer and want all panel chrome governed in one place. A third-party override on Filament's sidebar markup cuts across that.

How to Pitch It (Stakeholders)

To executives: A near-zero-cost quality improvement for the internal tools our teams use every day. Right now users fight a fixed-width sidebar that clips navigation labels — worse in non-English locales and in panels with deep, nested resource trees. This is a small, reversible plugin that lets each user drag the sidebar to the width that suits their workflow and keeps that choice. No data model changes, no migration, no vendor contract, no licence cost. Effort is measured in hours, not a sprint, and the risk is contained because the code is small enough to absorb in-house if the upstream project stalls. Recommendation: pilot on one internal panel, review in two weeks, then promote or drop.

To engineering: One Composer dependency plus one plugin registration in the Filament panel provider. No migrations, no queue or scheduled work, no meaningful config surface — it is a presentation-layer concern only. Review it as you would a pulled-in snippet: pin the exact version, read the source (it is small enough to finish in under an hour), confirm the constraint targets our Filament major, and check that the grip is keyboard-reachable, that any stored width degrades gracefully, and that asset registration goes through Filament's pipeline rather than inline injection. Because dependents are effectively zero, assume no upstream bus factor — be willing to fork on a Filament major upgrade rather than wait for a fix. Add a manual smoke-test line to the Filament upgrade runbook covering sidebar scrollbar reachability, drag behaviour, collapsed/mobile drawer, dark mode, and tenant switching. Roll out behind a feature flag for a cheap kill switch.

To design and support: The affordance to watch is the interaction between the resize grip and the sidebar scrollbar — that was the one defect in the first release, and it is the class of regression most likely to recur. Sign off on discoverability before pilot, and treat "navigation became unusable on short viewports" as the escalation path to watch for, since it degrades every admin user at once and throws no error.