Ux Sweet Alert Laravel Package

Product Decisions This Supports

• Feature scoping: Adopting this gives you standardized confirm/toast dialogs (destructive-action confirmations, post-submit flash messages, session-expiry and consent prompts) without hand-rolling a Stimulus controller around SweetAlert2. The value is in removing bespoke per-page JS, not in novel capability.
• Roadmap / upgrade planning: v0.21.0 adds Symfony UX v3.0 support. This is the material item in the release — it means the alert layer is no longer a blocker for a Symfony UX major-version upgrade. Treat it as a green light on a dependency that was previously a potential upgrade tax.
• Build vs buy: The wrapper is thin (one PHP/Twig helper plus a Stimulus controller over an established JS library). The build alternative is roughly a day of work plus ongoing ownership; the buy alternative is a small third-party dependency. For teams already on Symfony UX, adoption is cheaper than building. For anyone else, the calculus favors either building the thin wrapper or using their framework's native modal primitives.
• No migration work from this release: The Stimulus controller moving from JS to TypeScript is internal hygiene — no public API change, no config change, no deprecation. It should be booked as maintenance credit to the maintainer, not as a product-relevant change beyond the UX v3 compatibility.
• Use cases that qualify: Confirm-before-delete, revoke-access, and unsaved-changes guards; async flash messaging after form submits; low-stakes toasts. Use cases that don't: multi-step modal flows, server-driven modal composition, or anything that must visually match a formal design system.

When to Consider This Package

Adopt when all of the following hold:

• You are on Symfony UX (Twig + Stimulus). Important caveat: despite the "PHP package" framing, this is a Symfony UX bundle, not a Laravel-native package — there is no Blade or Livewire integration. Laravel teams should look at Livewire/Filament modal primitives or a plain SweetAlert2 JS wrapper instead.
• You need commodity dialog patterns (confirm, toast, simple prompt) rather than a general modal system.
• You have confirmed your Symfony UX major version. Supporting UX v3.0 is the headline change; teams still on UX 2.x should verify the release still resolves cleanly or pin to v0.20.1. Mixing UX majors is the primary upgrade risk here, not the package itself.
• Your blast radius is low — UI sugar on non-critical paths.

Look elsewhere when:

• You need accessible, design-system-conformant modals. SweetAlert2 renders outside your component hierarchy and composes poorly with larger design systems.
• You need server-driven or stateful modal content — this is a client-side prompt helper.
• You require vendor stability guarantees. This is pre-1.0 software with a single maintainer and irregular cadence. That is acceptable for peripheral UI affordances and unacceptable for flows where a regression blocks revenue or compliance.
• Your alert logic is genuinely one or two dialogs — the dependency overhead exceeds the code it replaces.

How to Pitch It (Stakeholders)

To executives: A low-cost, low-risk UI standardization. It replaces scattered, hand-written confirmation dialogs with one consistent pattern, which reduces a known class of accidental-destructive-action bugs and support tickets. No new infrastructure, no licensing cost, no vendor contract. The v0.21.0 release is maintenance-grade: it keeps us compatible with the current Symfony UX major version and modernizes the package's internal controller to TypeScript. There is nothing to migrate on our side.

To engineering: A composer-installable Symfony UX bundle wrapping SweetAlert2. v0.21.0 adds Symfony UX v3.0 compatibility and converts the Stimulus controller from JS to TypeScript — internal only, no public API or configuration changes, so the upgrade is a version bump. Usage is a Twig helper call. Two caveats to accept explicitly: it is Symfony-only (not usable from Blade/Livewire) and it is pre-1.0, single-maintainer, so pin the version, keep the adoption surface narrow, and note that our real dependency is the underlying SweetAlert2 API — the wrapper is replaceable if maintenance lapses.