Drawer Laravel Package

Product Decisions This Supports

• Build vs. buy for a commodity UI pattern. Slide-out drawers (off-canvas nav, filter panels, cart, settings) are well-understood UI with no differentiation value. This package converts a recurring 1–3 day build into a few hours of integration — a clear "buy" against an internal build, provided the dependency is contained (see below).
• Roadmap sequencing for admin and internal tooling. The highest-value fit is back-office surfaces: filter panels on listing pages, mobile navigation in admin, side-panel editors. These are typically under-resourced and can absorb a thin Blade component quickly, freeing design/engineering capacity for customer-facing work.
• Frontend stack containment. The explicit pitch — "no heavy frontend framework" — supports a deliberate product decision to keep Blade + minimal JS for server-rendered apps instead of introducing a SPA or component library for one interaction pattern. That has a measurable effect on page weight, build pipeline complexity, and hiring profile.
• Design-system and component standardization. A configurable position/size/overlay drawer with slot-based header/body/footer is exactly the shape of a reusable primitive. It can seed a Blade component library, or serve as the reference API your team reimplements when the dependency is replaced.
• Feature scoping for cart and checkout-adjacent flows. A drawer cart is a common conversion experiment. This makes it cheap to prototype — but it should not be the production dependency for a revenue-critical surface without forking or vendoring (see risk below).
• Dependency policy precedent. With a single maintainer, zero stars, and a patch release (1.0.1) that renamed the published config file — a consumer-visible breaking change — this is a useful test case for your team's policy on pinning, vendoring, and reviewing UI dependencies.

When to Consider This Package

Adopt when:

• The host app is Laravel on a conventional Blade/SSR stack, with no React/Vue/Inertia frontend that already ships a drawer primitive.
• You need two or more drawer instances (nav + filters + settings), so the abstraction pays for itself over hand-rolled markup.
• The surfaces are internal, admin, or non-critical — low blast radius if the package is abandoned or behaves unexpectedly.
• You want the config published, pinned (^1.0), and wrapped behind a single internal Blade component so the vendor API never leaks into feature code.
• Someone owns the upgrade path: diff published config against the stub after each release, config:clear in CI, config:cache in deploy.

Look elsewhere when:

• Accessibility is a hard requirement (WCAG/VPAT, public-sector or enterprise procurement). Focus trapping, aria-modal, escape-to-close, and scroll-lock behavior are not documented — assume you must verify and likely supplement them yourself.
• It would sit on a revenue-critical path (checkout, cart in production) without an internal fork. A one-maintainer package with no release notes beyond a single line is not a vendor relationship.
• You already have a component library — Filament, Livewire/Flux, Bootstrap offcanvas, Tailwind UI, or a design system. Duplicating a drawer primitive fragments your UI.
• You need rich interaction: drag-to-resize, stacked drawers, gesture dismissal, animated transitions, or SSR-safe hydration guarantees.
• You require support SLAs, security advisories, or a maintained changelog. The evidence here is thin: no visible test matrix, no supported Laravel/PHP version statement, no artifact review.
• Your team is comfortable building this in a day. A drawer is ~100 lines of Blade, a CSS transition, and a focus trap — owning it removes the upgrade tax entirely.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that removes a repeated piece of UI work — slide-out panels for navigation, filters, and carts — from our backlog. It keeps our stack server-rendered instead of adding a JavaScript framework, which protects page performance and avoids a new frontend build pipeline. The trade-off is dependency risk: the project has a single maintainer, no meaningful adoption signal, and its last release silently changed a configuration filename in a patch version. That is acceptable only because we will contain it — pinned version, wrapped behind our own component, limited to internal and admin surfaces. Expected cost: roughly half a day to integrate and verify, one to two hours per future upgrade. Recommendation: pilot on one admin surface, do not standardize until it has survived an upgrade cycle.

To engineering: Treat this as a thin Blade primitive, not a platform. Publish the config first and read it end to end — as of 1.0.1 the file is sb--prefixed, so any pre-existing config is orphaned and the package will silently fall back to defaults. Check config('sb-*') in tinker before writing feature code; a filename/key-namespace typo returns null with no error. Pin to ^1.0, add a config assertion to the boot test suite, ensure config:clear runs in CI and config:cache runs in deploy after the file exists. Wrap the package in one internal Blade component so a swap is a one-file change, and assume we own the accessibility work — verify focus trap, escape handling, and scroll lock ourselves rather than trusting the docs.