livewire-alert: SweetAlert2 notifications driven from PHP

A facade that builds an alert and shows it

livewire-alert is a Laravel Livewire package that brings SweetAlert2 notifications to your Livewire components through a fluent, chainable API. The stated promise is that you can configure and trigger interactive alerts with a clean PHP interface and no JavaScript required.

The shape of the API is the whole idea. A call starts at the facade, sets a property, picks a type, and ends with the show call:

use Jantinnerezo\LivewireAlert\Facades\LivewireAlert;

public function save()
{
    LivewireAlert::title('Changes saved!')
        ->success()
        ->show();
}

Because Livewire components already have a server round trip for anything the user does, raising an alert from the server side is the natural place for it. The component method that handled the action knows what happened, and the alert is part of that same response rather than something the front end has to reconstruct from a payload.

The facade lives under the Jantinnerezo namespace and resolves through the package's own service provider. The configuration file can be published if you want to change the defaults, and the documented feature list covers icons, positions, toasts, timers, buttons, confirm dialogs, loading alerts, in place updates, inputs, flash alerts, images, custom classes and dependency injection, all documented with copy pasteable snippets and runnable demos on the documentation site.

Installing the package and the configuration

The requirements are PHP 8.1 or higher, Laravel 10.x or higher, Livewire 3.x or 4.x, and Composer.

The package itself installs with a single Composer command:

composer require jantinnerezo/livewire-alert

The configuration file is optional to publish, and the tag to use is the package's own:

php artisan vendor:publish --tag=livewire-alert:config

Publishing is only worth it if you are changing defaults, and the README is clear that the package works without it.

The third step is the one that catches people out, because it is outside the package. SweetAlert2 is a separate front end dependency and this package does not ship it, so you install it yourself with npm or yarn:

npm install sweetalert2

or the Yarn equivalent:

yarn add sweetalert2

So the full dependency picture is a Composer package on the server and an npm package on the client, plus the JavaScript glue between them. That is not a criticism, it is how a Laravel application is usually assembled, but it does mean that a livewire-alert install is not complete until the front end part is done, and that a page which does not load SweetAlert2 will not show an alert even when the PHP call succeeds.

Loading SweetAlert2 into the front end

The README gives two ways to get SweetAlert2 on the page, and the bundler route is the one to use in a Laravel application that already has a front end build.

With a bundler you import the library and expose it on the window object, in resources/js/app.js:

import Swal from 'sweetalert2'

window.Swal = Swal

The assignment to window is the part that matters, because the package needs to reach the global to trigger a dialog.

The alternative is a script tag from a CDN, included before the closing body tag:

<script src="https://cdn.jsdelivr.net/npm/sweetalert2@11"></script>

That version pins SweetAlert2 to the 11 series and skips the bundler entirely, which is quick for a prototype and reasonable for a page that does not otherwise need a build step. The cost is that a CDN hosted script is now part of your page's supply chain, and the version is fixed in the markup rather than in your lock file.

The documentation site covers the same ground with runnable examples, and the README explicitly points everything beyond the quick taste there.

Filament applications register it as an asset

If your application runs on Filament, the setup differs slightly because Filament controls which assets are loaded on its pages. The README shows registering SweetAlert2 as a Filament asset in your AppServiceProvider:

    FilamentAsset::register([
        Js::make('sweetalert2', Vite::asset('resources/js/sweetalert2.js')),
        // Or via CDN:
        // Js::make('sweetalert2', 'https://cdn.jsdelivr.net/npm/sweetalert2@11'),
    ]);

The pattern is the same as the plain approach, just routed through FilamentAsset::register so that Filament includes the script on the pages it renders. The Vite version points at a file in your own project, which keeps the dependency in your lock file, and the commented alternative points at the CDN version, matching the choice you made for the rest of the application.

That consistency is worth pointing out. Whichever way you load SweetAlert2, do it the same way in the Filament and non Filament parts of the application, because a mismatch shows up as an alert that works in one screen and silently does nothing in another.

The v3 to v4 break and the fluent facade

The README keeps a short section for people arriving from the older line, and it is important for anyone with an existing project.

The last v3 release was v3.0.3, dated March 11, 2024. v4 is a major refactor that introduces the fluent Facade API, dependency injection and many more features, and the v3 line is still installable with:

composer require jantinnerezo/livewire-alert:^3.0

The recommendation in the README is to upgrade to v4 for new and ongoing projects, which is a reasonable position for a package whose major version exists precisely because the calling convention changed. The two lines are not source compatible, since the fluent facade is the v4 interface and the v3 API is a different shape, so a migration is a rewrite of the call sites rather than a version bump.

The v4 release line has been busy. v4.0.9 came out on 2026-03-24, v4.1.0 on 2026-04-04, and v4.2.0 on 2026-05-18, with that last release described as driving loading spinners and live alert updates straight from PHP.

That last phrase is the interesting one, because it describes the direction the package has been moving. A loading spinner that the server can start and finish is only possible if the alert is state on the Livewire side rather than a one shot command, which is a different model from the classic browser confirm dialog.

Alerts driven from PHP: loading states and live updates

The v4.2.0 release note points at the feature that distinguishes this package from a thin wrapper around a JavaScript alert call.

The classic SweetAlert2 confirm dialog is a promise in the browser, and in a Livewire application that model is awkward, because the decision has to travel to the server and back. Driving the spinner and the completion from PHP inverts that, letting the server say that something is in progress and then say that it is done.

The broader feature list on the documentation site supports the same reading. Loading alerts, in place updates, flash alerts and timers are all things that suggest a stateful model rather than a single modal. Toasts for transient messages, confirm dialogs for decisions, inputs for values collected in the dialog, and images for richer content fill out the same surface.

Dependency injection is listed among the features, which in a Livewire package means the alert behaviour can be resolved rather than hard coded. For an application with several notification styles, or one that wants to swap the frontend library later, that is the part of the design with the longest lasting value.

The repository itself is small, with src/ for the package code, config/ for the publishable configuration, tests/ for the suite, composer.json, and both phpunit.xml and phpunit.xml.dist. The README badges show a PHPUnit build and a separate PHPStan analysis job, so the package is type checked as well as tested.

Where livewire-alert is the wrong tool

Three cases point elsewhere.

The first is an application that does not use Livewire. The package is built around Livewire components and its lifecycle, and in a plain Blade application or a Livewire 2 project it is the wrong shape, with the v3 line being the only thing that might apply and its API being different.

The second is a team that wants no alert library. Every dialog is a dependency on SweetAlert2 and on the global it exposes, and if your design system already has a notification component, or your users are on a locked down environment where a CDN script is not acceptable, this package adds a layer without removing one.

The third is a use case that is not a notification. The package covers alerts, toasts, dialogs and loading states. Anything like a wizard, a multi step form or a bespoke overlay is your own code, and the fluent API will not get you there.

Two operational points to weigh. The library is on the client, so a page that fails to load SweetAlert2 will produce no alert and no error in the server log, which is a failure mode that is easy to misread as a bug in the package. And the version story is unsettled in a way that matters for long lived projects, because the v3 line has had no release since March 2024 while v4 has been releasing monthly, so a project that stays on v3 is choosing a line that is no longer moving.

Editorial conclusion

Adopt livewire-alert if you build Laravel applications on Livewire and want confirmation dialogs, toasts and loading states with the SweetAlert2 look, without each component hand rolling a JavaScript call. Do not adopt it if your application does not use Livewire, if you want to avoid the SweetAlert2 dependency entirely, or if you are still on Livewire 2 and expect the v3 API. Verify three things first: that your PHP, Laravel and Livewire versions fall inside the stated requirements of PHP 8.1 or higher, Laravel 10.x or higher and Livewire 3.x or 4.x; that SweetAlert2 is actually loaded on the page, because the package does not bundle it and the browser will show nothing otherwise; and whether the v4 fluent facade API is what you want, since the v3 line stopped at v3.0.3 in March 2024 and the two versions are not interchangeable. The licence is MIT, the last push was on 2026-05-20, and the newest release is v4.2.0 dated 2026-05-18.

Frequently asked questions

Official sources

1. jantinnerezo/livewire-alert on GitHub
2. License: MIT
3. Project website
4. README
5. Releases