Resizable Modal Laravel Package

Product Decisions This Supports

• Admin UX polish as a roadmap line item. Filament action modals are a high-traffic surface in most admin panels we ship; drag-to-resize is a small, visible quality-of-life gain that users notice without training. This package is a candidate to close a recurring "the modal is too small for my table/form" complaint without dedicating a sprint.
• Build vs. buy for micro-interactions. The feature is genuinely small (resize handles on a modal). This package lets us frame the decision as "adopt a ~free MIT plugin" vs. "spend engineering hours reproducing it." If the buy side is credible, we avoid a bespoke implementation and its maintenance tail.
• Platform/ecosystem posture for Filament-based products. If our admin panels standardize on Filament v4/v5, we need a stance on third-party plugins: which categories we accept (cosmetic, isolated, forkable) and which we don't (auth, data, permissions). A resizable-modal plugin is a clean test case for that policy.
• Prioritization signal for "polish backlog" vs. "core features." Because the package is cosmetic and reversible, it's a low-cost way to demonstrate responsiveness to internal admin users while keeping the roadmap focused on revenue-facing work.
• Use cases it unlocks: data-dense action modals (bulk edits, previews, comparison views), side-by-side review workflows, and support/ops teams who keep several modals open while triaging. These are real but narrow; the decision is "cheap nice-to-have," not "unlocks a new segment."

When to Consider This Package

• You are on Filament v4 or v5. The plugin targets those versions specifically; earlier versions are out of scope and should look elsewhere or accept a manual CSS/JS shim.
• Action modals are a genuine friction point. If internal users or customers repeatedly maximize/resize or complain about cramped modals, the payoff is immediate and measurable via support tickets or session recordings.
• You can accept a small, single-maintainer dependency. With ~8 stars and zero dependents, treat this as "adopt-and-vendor," not "adopt-and-rely." Budget a fork and pin the version.
• The blast radius is acceptable. It's a UI-only, MIT-licensed plugin touching how modals render; it does not sit in the auth, data, or payment path. That makes a pilot low-risk.
• You have a lightweight plugin review process. A quick code read for JS/CSS injection, Alpine/Livewire interactions, and upgrade compatibility should be enough.

Look elsewhere (or build/decline) when:

• You aren't on Filament, or you're on v3 or earlier.
• The requirement is trivial to satisfy in-house — if a small CSS/JS tweak in your theme achieves 80% of the benefit, a dependency isn't worth it.
• You need guaranteed support, SLAs, or a large community. Stars and dependents are low; a single maintainer is a bus-factor risk.
• You need more than resize: persisted sizes per user, keyboard/accessibility affordances, or multi-monitor behaviors. Verify these exist; don't assume.
• Your org has a strict dependency policy (minimum adoption thresholds, security review requirements) that this package won't clear without an exception.
• A Filament major-version upgrade is imminent and you don't want to carry an unmaintained plugin across it.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk admin-experience improvement. It's MIT-licensed and cosmetic — it makes action modals resizable so ops and support users can work with dense data without fighting the UI. Cost is effectively zero in license fees and hours in integration. The trade-off is dependency hygiene: it's a tiny, single-maintainer project, so we'd vendor the code rather than bet on it. Recommendation: pilot it behind our admin flags and revisit in a quarter. It's a "yes, cheaply" — not a strategic bet.

For engineering: Drop-in Filament v4/v5 plugin adding drag handles to action modals. Isolated, UI-only surface; no data, auth, or schema impact. Small codebase, MIT — plan to fork and pin rather than track upstream. Review for Livewire/Alpine interactions and modal lifecycle edge cases before rollout. Keep it behind a config flag so we can disable without a deploy rollback.

Decision framing: Approve as a time-boxed pilot with vendoring, not as a standard dependency. Success = fewer "modal too small" complaints and no upgrade friction; kill criteria = maintenance burden during the next Filament upgrade or any rendering regression.