Sweet Alert Laravel Package

Product Decisions This Supports

• Build vs. buy for modal/toast/confirm UX. This is a thin, MIT-licensed Laravel binding over SweetAlert2, which is the de facto standard for JS dialogs. The buy case is strong: you get WAI-ARIA-accessible dialogs, theming, input types, toasts, and animations without maintaining any front-end code. Building this in-house means owning accessibility compliance and cross-browser dialog behavior forever. Estimate a two-to-four week build for parity, plus ongoing maintenance — spend that on the product instead.
• Confirmation flows for destructive actions (the highest-value use case). Deletes, refunds, publishes, account closures. The data-confirm-delete / data-confirm attributes let you guard any link or form declaratively, with per-element copy overrides (data-confirm-title, -text, -icon, -button, -cancel). No bespoke JS per screen, which means PMs can spec confirm copy as content, not as an engineering ticket.
• A correctness fix masquerading as a UX feature. In v7, a guarded delete link was only guarded on the request where confirmDelete() had been flashed; on any other render the link was plain HTML and the browser issued a GET to the destroy URL. v8's listener is always present, and if the SweetAlert2 CDN is unreachable it falls back to the browser's native confirm(). That's a "destructive action can never fire unasked" guarantee — worth prioritizing on its own, and a good line item for a security review.
• Reducing validation-error and flash-message surface area. The middleware can surface Laravel validation errors as dialogs, and session flashing means controllers can return alerts without touching views. This removes a recurring class of "we forgot to show the error" bugs from your backlog.
• Input collection without a new screen. Alert::input(...)->submitTo(route(...), 'POST', 'field') collects a single value (a name, a reason for cancellation, a refund note) and posts it to your server. This is a cheap way to ship "capture a reason" features that would otherwise need a form page and a route and a validation request.
• Toast positioning and layering as a design-system decision. topLayer() puts popups in the browser's top layer above any z-index, which closes the perennial "toast renders behind the navbar" bug. Treat this as a design-system constraint you can specify once rather than a per-page fix.
• Roadmap alignment signal. The package ships support for Laravel 11/12/13 on PHP 8.3+, publishes a Laravel Boost guideline so AI assistants generate v8 rather than v7, and includes a tokenizer-based alert:upgrade codemod. If your roadmap includes a Laravel upgrade, the package's release cadence tells you it will follow you; that is a real (if modest) input to sequencing.

When to Consider This Package

Adopt when:

• You are on Laravel 11, 12 or 13 with PHP 8.3+. Below that, you are on a frozen major (v7.x) and should treat this as legacy maintenance rather than a new adoption.
• You have repeated confirmation/toast/validation-dialog needs across many screens — the sampled applications showed Alert::success() in 52 files. If usage is broad, the abstraction pays for itself; if it's two dialogs, it doesn't.
• You want accessible dialogs without an accessibility workstream. The WAI-ARIA framing is a genuine compliance argument, not marketing.
• You are not already standardized on a JS component library (Livewire/Alpine component, Inertia + Vue/React modal, Bootstrap/Tailwind dialog kit). If you are, adding a second dialog system creates two visual languages and two accessibility stories — use the one you have.
• You accept no JS build step: assets are published and served from vendor/, with optional CDN. That's a plus for teams without a front-end pipeline, and a downside for teams with a strict CSP or a bundle-size budget.

Look elsewhere when:

• You need a rich modal primitive — multi-field forms, wizards, embedded components, focus-trapped drawers. SweetAlert2 is a dialog, not a modal framework; submitTo() handles one field, not a form.
• Your CSP forbids inline styles. SweetAlert2 applies background, width and padding as inline styles that beat every stylesheet — this is why v8 defaults them to null. Theming and CSP can fight each other here.
• Single-maintainer risk is disqualifying. Stars (~1.2k) are decent for a Laravel utility, but the dependents count reads as zero — thin third-party adoption signal. If your organization requires two active maintainers or an SLA, this fails. Mitigation: pin the minor version, keep usage behind a small internal Alerts helper, and budget a day per Laravel major for upgrades.
• You need localization of dialog chrome beyond button text. Confirm/cancel labels are configurable; broader i18n may require custom work.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, MIT-licensed Laravel package that gives our app professional, accessibility-compliant popups — confirmations, success/error messages, toasts, and simple input prompts — without us building or maintaining any front-end dialog code. The concrete win is around destructive actions: deleting a record, refunding an order, closing an account. Today those confirmations are bespoke per screen, and the v7 version of this package had a real defect where a "guarded" delete could execute without being confirmed. The current version guarantees a confirmation is always shown, and falls back to the browser's own prompt if the CDN is unavailable. Cost is effectively zero; the risk is that it's a small open-source project with one primary maintainer, which we manage by pinning versions and wrapping our usage behind a thin internal helper so we could swap it out in a day.

For engineering (the short version): It's a Laravel-native builder over SweetAlert2 — AlertBuilder, ToastBuilder, InputBuilder, PHP 8.3 enums (AlertType, InputType, Position), when()/unless()/macro() on every builder, a @sweetAlert Blade directive replacing @include('sweetalert::alert'), and Livewire v4 / Inertia middleware support. Declarative guards for forms and links (data-confirm, data-confirm-delete, data-confirm-method) build a CSRF-correct form and submit it for you, so no per-screen JavaScript. It ships Pest tests, PHPStan level 5, Pint, and a tokenizer-based php artisan alert:upgrade --dry-run codemod that rewrites the two changed signatures and the config keys — validated against five real applications, 1,065 files scanned, 16 rewritten, no false positives. Watch out: v7's html($title, $code, $icon) became html($html) in v8, and PHP silently ignores the surplus arguments, so an un-migrated call doesn't error — it just stops working. Run the upgrade command. Requirements: PHP 8.3+, Laravel 11/12/13.

What I'd ask for: Approve adoption for the confirmation/toast use case only, pin to the current minor, and require that all usage go through a single internal Alerts wrapper so we retain the option to replace it. Revisit if the maintainer goes quiet for two consecutive Laravel majors.