realrashid/sweet-alert
Laravel package that brings SweetAlert2 to your app with a fluent PHP API. Flash success, error, and toast alerts, or build confirm dialogs right from your controllers—no JavaScript boilerplate needed.
Architecture fit. This is a presentation-layer adapter, not infrastructure. It converts a fluent PHP call or a flashed session key into an inline <script> block that invokes SweetAlert2 (MIT, bundled) on the next full page render. There is no persistence, no schema, no queue, no service dependency, and no outbound network call at request time in the bundled configuration. That makes it architecture-neutral: it cannot contaminate a domain model, and removing it is a mechanical exercise. The corollary is that it sits entirely outside our tested application core — its blast radius is UX dead-ends and asset delivery, not data integrity.
Integration feasibility. Low effort, high certainty, provided we are on the supported matrix: PHP 8.3+ and Laravel 11/12/13. Teams on Laravel 10 or below are frozen on the v7.x line and effectively on a maintenance branch; that is a sequencing constraint, not a blocker. v8 adds a Blade directive (@sweetAlert) replacing @include('sweetalert::alert'), a Livewire v4 trait, and an Inertia middleware — the last two matter because the flash-and-render model does not work for JSON responses or partial SPA navigation without them. The data-confirm / data-confirm-delete guarded-action layer is the highest-value capability: it builds and submits a CSRF-bearing form with the correct HTTP method on confirm, and falls back to the browser's native confirm() if SweetAlert2 cannot be fetched. That is a fail-closed design, which is the right default for destructive actions.
Technical risk.
html() changed from html($title, $code, $icon) to html($html). PHP ignores surplus arguments, so un-migrated calls do not error — they stop rendering. This is the single most dangerous item in the upgrade and the reason php artisan alert:upgrade --dry-run exists (tokenizer-based, not text-search, so it won't rewrite lookalike calls on unrelated objects).background, width, and padding now default to null because SweetAlert2 applies them as inline styles that outrank every stylesheet. A v7-era published config silently defeats theming.Alert::warning under Laravel 12; the fix landed in v7.3.2. The pattern — major-version support announced, compatibility patch follows — is the one to plan around.data-confirm-delete listener is now always present. Fixes a genuine defect (previously a link rendered without the flash was an ordinary link and issued a bare GET against the destroy URL — a destructive GET), but it changes DOM behaviour application-wide and can collide with existing JS bound to the same selectors.html() accepts raw markup. Safe for developer-authored strings; a review gate if any of it is interpolated from user data.Key questions. What is our CSP, and does it permit a CDN origin — or do we ship the bundled asset? Is the consuming surface Blade, Livewire, or Inertia, and is there a JSON-only surface where this is simply the wrong tool? What are our WCAG targets, and has the WAI-ARIA claim been validated against them rather than asserted? Do we localize confirm/cancel copy, and for which locales? Who owns the SweetAlert2 version bump cadence and its CVE review? And the product question underneath all of it: are modals the right feedback mechanism here, or are we adding interruptive dialogs where inline validation would serve users better?
Stack fit. Strongest in a Blade-rendered monolith with session-backed flash. Adequate in Livewire (trait) and Inertia (middleware). Unsuitable as a server package for an API-only backend — there, use SweetAlert2 directly from the frontend bundle and treat this package as out of scope entirely.
Migration path. Branch, then php artisan alert:upgrade --dry-run and read the report before writing anything — the command never touches vendor/ and asks for confirmation. Manually audit every ->html() call regardless of what the tool reports. Diff the published config against the shipped one for the three theming keys. Verify the Alert facade binding resolves after the container change. Then a smoke pass over one representative destructive action before merging.
Compatibility. Pin the major version explicitly and record the Laravel/PHP combination it was validated against, because that combination is the real support contract. Confirm the bundled SweetAlert2 version and its license state at pin time. For Laravel ≤10, pin v7.x and accept feature freeze.
Sequencing. (1) Pilot on an internal admin surface with a single data-confirm on a destructive action — lowest exposure, highest signal. (2) Measure first-click latency and payload delta with the bundled asset always loaded versus fetch-on-click. (3) Decide the asset strategy: bundled local, CDN, or Vite-managed — one decision, applied uniformly. (4) Roll guarded confirms to all destructive actions, per-element copy overrides included. (5) Adopt validation-error surfacing last and only after confirming it does not duplicate inline field errors. (6) Schedule the v8 migration as its own change, not folded into a feature release.
Maintenance. Steady but non-trivial: the changelog is dominated by "Upgraded SweetAlert2 to latest version," which means upstream JS currency is the project's main ongoing work and therefore ours. Budget a recurring review, not a one-time install. v8's Pest suite, architecture tests, Pint, and PHPStan level 5 give reasonable confidence — level 5 of 9 is meaningful but not strict, so don't treat static analysis as a guarantee.
Support. Community-only. Documentation is real (VitePress, upgrade guide, changelog, SECURITY.md, Boost AI guidelines) and better than typical for the star count, but there is no escalation path. Internal ownership must be named: one engineer accountable for version pins and security review.
Scaling. Per-request cost is negligible — this is string concatenation into a response body. The scaling concern is client-side: shipping sweetalert.all.js on every page inflates payload and affects Core Web Vitals; fetch-on-click for guarded links keeps a page with only a guarded link at zero JS until interaction. Prefer the lazy path, and treat CDN dependence at click time as a deliberate tradeoff given the native-confirm() fallback.
Failure modes. CSP blocks the script → dialogs never appear and guarded actions may degrade to unguarded navigation; test the fallback explicitly. CDN outage → native confirm() takes over, which is acceptable but visually inconsistent. Flash consumed by an intermediate redirect or a non-rendering response → alert silently vanishes; in SPA flows this manifests as "the toast didn't show" bug reports with no server-side trace. Multiple alerts in one request → confirm rendering priority, not stacking. Toast behind a fixed navbar → this is exactly what topLayer() addresses; verify it in the target browsers. Middleware auto-surfacing of validation errors → duplicated messaging if inline errors are already rendered.
Ramp-up. Under a day for a Laravel developer; the fluent API and enums (AlertType, InputType, Position) make it discoverable, and the v8 Boost guidelines mean AI-assisted code lands on the current API rather than the v7 one. The real training point is discipline, not syntax: it is a dialog and confirmation primitive, not a general modal system. Pushing complex Blade forms through html() should be a documented anti-pattern, because it trades a maintainable view for a string and reintroduces the XSS question.
How can I help you explore Laravel packages today?