Laravel Sweetalert2 Laravel Package

Product Decisions This Supports

• Buy vs. build for notification/confirmation UX. This replaces the in-house "flash message + hand-rolled SweetAlert glue" that most Laravel apps accumulate. Adopting it is a small, reversible decision — the real cost is a composer require and a config file, not a sprint.
• Safety on destructive actions, cheaply. data-swal-confirm on any button, link, or form (including wire:click/wire:submit) turns "confirm before delete" into an attribute rather than a JS story. This is the strongest product argument: fewer accidental deletions and misfires, with near-zero implementation cost.
• Multi-step flow UX. Popups survive chains of redirects and multiple popups can queue per request — supports onboarding steps, post-checkout messaging, and "your export is ready" patterns without server-side session hacks.
• Framework upgrade sequencing. PHP 8.3+ and Laravel 12/13 are hard floors. If you're on Laravel 10/11, this package becomes an argument for scheduling the framework upgrade rather than a blocker you can work around.
• Asset delivery strategy. SweetAlert2 11.26.25 ships from jsDelivr with SRI, not from npm/Vite. That's a deliberate governance decision (CDN vs. lockfile-pinned bundle) that should be made once, explicitly, and applied consistently — not decided per-package.
• Stack fit for Livewire/SPA navigation. The data-navigate-once handling and the SweetAlerts trait mean this works under wire:navigate without flicker or duplicate handlers — relevant if the roadmap includes Livewire-first or SPA-feel navigation work.
• Scope discipline. This is commodity UI plumbing, not a differentiator. Treat it as low-risk infrastructure; don't let it into roadmap debates about notification architecture.

When to Consider This Package

Consider it when:

• The app is on Laravel 12 or 13 with PHP 8.3+ — this is non-negotiable.
• The stack is Blade-first, optionally Livewire, and you want session-flashed popups that survive redirects.
• You need confirmation dialogs on destructive or irreversible actions and want them declarative (attributes) rather than bespoke JS per screen.
• You want toasts and alerts with escaping-safe defaults — titles go out as titleText, button labels and footers are HTML-escaped, with html()/raw() as explicit, greppable opt-outs. That's the right default posture for a team that will inevitably pass user-supplied strings into messages.
• You're migrating off the never-published amjadiqbal/sweetalert2 and want the namespaced session key (laravel-sweetalert2.alerts) and swal() helper that don't collide with amjadiqbal/alertify.

Look elsewhere when:

• You're on Laravel 10/11 or PHP < 8.3. No amount of configuration fixes this; don't plan around it.
• Third-party CDNs are off-limits — air-gapped environments, strict supply-chain policy, or a CSP that won't allow jsDelivr. SRI mitigates tampering but not availability or policy.
• You need npm/Vite-pinned assets under a lockfile for reproducible builds or vendored JS.
• Your design system already owns notifications. Two notification layers is worse than one adequate one.
• The front end is Inertia + React/Vue. The facade and session flashing still work, but the Blade component and @sweetalert2 directive are dead weight; you'd be adopting half a package.
• You need richer modal primitives (drawers, forms-in-modal, multi-field dialogs). SweetAlert2 is an alert library; it is not a dialog framework.

How to Pitch It (Stakeholders)

For executives. A small, single-purpose library that adds polished alerts, toasts, and — more importantly — confirmation prompts before destructive actions. The business case is risk reduction: accidental deletes, irreversible submissions, and "did you mean to do that?" moments become handled by default instead of by whichever engineer remembered to write the JS. Cost is a handful of lines in composer.json; there is no vendor lock-in, no data model change, and no migration. Two caveats to state plainly: it is v1.0.0 from a single maintainer with no prior published track record, so pilot it on a non-critical surface first; and it loads SweetAlert2 from a public CDN rather than a bundled asset, which is a policy question for security/ops, not an engineering one. Mitigations exist (SRI hashes, CSP nonces), but the CDN decision should be made deliberately.

For engineering. One composer require amjadiqbal/laravel-sweetalert2. You get a SweetAlert2 facade, a swal() helper, and success/error/warning/info/question/toast/fire that flash to the session — so popups survive redirect chains and multiple popups queue correctly. Fluent options cover timer, position, confirmButton, cancelButton, footer, theme, width, plus option()/raw() escape hatches. Front end is <x-sweetalert2 /> and @sweetalert2, loading SweetAlert2 11.26.25 with SRI, a small runtime, a Vite CSP nonce on every script tag, and data-navigate-once so wire:navigate doesn't double-bind. Livewire components get a SweetAlerts trait ($this->swal(...), $this->swalToast(...)). Security defaults are correct: titles ship as titleText, labels and footers are escaped, and html()/raw() are the explicit opt-outs — enforce those in review. Session key and container binding are namespaced (laravel-sweetalert2.alerts, sweetalert2), so no collision with amjadiqbal/alertify. CI is 29/29 across PHP 8.3/8.4/8.5 × Laravel 12/13 with Pint, PHPStan, and Pest. Note the breaking deltas from the unpublished predecessor: type is now icon, and the global helper is swal(), not alert() — relevant only if anyone copied patterns from that branch.