# Laravel SweetAlert v8: a rewrite of the alert library around a fluent builder

> Version 8 of the Laravel SweetAlert package rebuilds the library from scratch with three purpose-built builders, PHP 8.3 enums, a Blade directive, a Livewire trait, Inertia middleware and guarded actions, and it ships a command that migrates a v7 codebase after showing you a dry run.

**realrashid/sweet-alert** — A BEAUTIFUL, RESPONSIVE, CUSTOMIZABLE, ACCESSIBLE (WAI-ARIA) REPLACEMENT FOR JAVASCRIPT'S POPUP BOXES FOR LARAVEL

- Repository: https://github.com/realrashid/sweet-alert
- Website: https://realrashid.github.io/sweet-alert
- Stars: 1,158 · Forks: 167
- Language: PHP
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/realrashid-sweet-alert

## v8.0.0 is a rewrite, and the release note says so

The package is a beautiful, responsive, customizable and accessible replacement for JavaScript popup boxes in Laravel, and the description of the current version is careful about what changed: rebuilt from scratch with a fluent, Laravel-native API.

The release title for v8.0.0, published on 2026-09-07, is exactly that, a complete rewrite. The releases before it are v7.3.2 from 2026-03-29 and v7.3.1 from 2026-03-28, so the project was maintaining the old line right up until the new one arrived, and then replaced it in one step.

That is why the package ships a migration command. Upgrading from v7 is handled by `php artisan alert:upgrade`, and the README makes a point of the order of operations: see what would change before anything is written, with a `--dry-run` flag.

There is a second, smaller sign of the rewrite in the feature list. The package is Laravel Boost ready, and it ships a guideline and a skill so that AI assistants write v8 code and not v7. A package that ships instructions for code generators is telling you that the v7 and v8 APIs are different enough that a model trained on older code will get it wrong, which is a fair description of any major rewrite.

The project is MIT licensed, the primary language is PHP, the default branch is `main`, the last push was on 2026-09-07, and the documentation is published at `realrashid.github.io/sweet-alert` with sections for getting started, alerts, toasts, the Livewire integration and an API reference. The author is Rashid Ali.

## The fluent builder is the API

The central design decision is that an alert is built by chaining methods, in the same style as an Eloquent query.

From a controller:

```php
use RealRashid\SweetAlert\Facades\Alert;

Alert::title('Welcome!')
    ->success()
    ->text('Your account has been created.')
    ->flash();

return redirect()->route('dashboard');
```

Every step returns the builder, so the call reads as a sentence about the alert, and `flash()` is what makes it survive the redirect that follows. The pattern of building a message, then handing it to the session and redirecting, is the Laravel way of saying something after a form submission, and the package makes it a one-liner.

There is also a global helper for the cases where a builder is more ceremony than the situation needs:

```php
alert('Success!', 'Your data has been saved.', 'success');

return redirect()->back();
```

Three arguments, title, text and type, and the same effect. A package that offers both is making a sensible point: the fluent form is for the alert with five options, and the helper is for the one with a title and a line.

The facade is the entry point, so the package is configured the Laravel way, through a service provider and a facade rather than through a class you instantiate. And the builder style is explicitly compared in the README to Laravel Eloquent, which tells you the audience: a Laravel developer who is used to reading a chain of method calls as a description of an operation.

## Three builders and three enums instead of one god object

The v8 feature list names three purpose-built builders: `AlertBuilder`, `ToastBuilder` and `InputBuilder`, and the distinction between them is the reason the rewrite was worth doing.

An alert, a toast and an input are three different things. An alert is a modal dialog with a title, a message and a set of buttons, and it blocks the interaction until it is dismissed. A toast is a transient notification that appears and goes away, and it has no buttons to speak of. An input is a dialog with a field in it, and it has to return a value, which means it has a confirmation path and a cancellation path and a result.

In a v7 style API those are usually methods on one builder, which means every alert object carries the ability to be a toast and every toast object carries the ability to ask for input. With separate builders, the type of the thing you are building is visible in the class you are building, and the IDE can complete the right set of methods.

The second half of the typing story is the enums. The package requires PHP 8.3 or later and ships `AlertType`, `InputType` and `Position` enums, with IDE autocompletion. So the type of an alert, the kind of input field and the position of a toast are closed sets of named values rather than strings, and a typo in an animation name is a compile-time problem rather than a runtime one.

The rest of the coverage is the SweetAlert2 feature set that the original library is known for, and the README says the package has full coverage of it: inputs, deny buttons, the pre-confirm hook, animations and themes. The pre-confirm hook is the interesting one, because it lets the package ask a question before the action happens and let the answer decide whether it proceeds.

## One Blade directive, three frontend stacks

An alert library has to get from PHP to the browser, and the package supports three routes.

The Blade route is the simplest. The layout needs the directive, and the directive is the bridge:

```blade
<head>
    ...
</head>
<body>
    ...
    @sweetAlert
</body>
```

The Livewire route is for applications that never leave PHP on the server. Livewire v4 support is first class, through a `SweetAlertTrait` that dispatches alerts as browser events. The mechanism matters: the alert travels as an event that the Livewire layer picks up, so the component that triggered it does not need to know how the dialog is rendered.

The Inertia route is for applications with a Vue or React frontend, and it works through middleware that shares the alert with the frontend, so the JavaScript side can raise the same dialog the Blade side would.

Having all three is a deliberate bet about where Laravel applications are going, and it is the kind of bet that is easy to make and awkward to undo, since an alert that is raised through one route cannot easily be shown by another.

The demonstration application, AlertDeck, is a Laravel app that exercises every alert the package can produce, in Blade, in Livewire and in Inertia, along with the guarded action attributes, all seven themes and routes migrated from v7 by the upgrade command. That is a better test of a UI package than a unit test suite, because a dialog is a thing you have to look at, and a package that documents its own demo application is telling you where to look.

## Guarded actions put a confirmation in an attribute

The feature list has one entry that is not about the dialog itself, and it is the one that saves the most JavaScript.

Guarded actions: `data-confirm` asks before any link or form goes through, with no JavaScript to write. A link that deletes something carries the attribute, the browser asks, and the request goes ahead only if the answer is yes.

This is a small feature with a wide reach, because a destructive action in a Laravel application is usually a link in a table row or a form button, and the usual implementation of a confirmation dialog is a chunk of JavaScript per view, or a framework helper, or a `onclick` attribute that breaks when the row is rendered by a component. A `data-confirm` attribute is a piece of markup that survives all of that, because the behaviour is attached to the document rather than to the element.

The AlertDeck demo exercises the guarded action attributes alongside the alerts themselves, which suggests the author sees them as part of the same feature: a library that can raise a dialog can also use that dialog to confirm an action, and doing it with one mechanism is simpler than having two.

There is a design question in there that the documentation has to answer, and the seven themes are part of the answer. A confirmation dialog in an application with its own design system has to look like the application, which is why the themes and the customization options are on the same feature list as the dialogs themselves.

## Where this package is the wrong tool

Three limits are worth stating, and the first is the biggest.

The first is the rewrite. Version 8.0.0 is not an increment, it is a different library with a different API, and the migration path is a command that a team has to trust. The `--dry-run` flag exists for that reason, and the sensible order is to run it, read what it would rewrite, and check the result by hand rather than letting a script edit a codebase that has custom alert calls in it.

The second is the scale of the dependency for what it does. A browser can confirm an action natively, with a `confirm` call or a `dialog` element, and it will be accessible, because it is the platform. What the package adds is a look, and a set of behaviours the native control does not have: the styling, the animations, the theme, the input dialogs, the toast placement, the deny button, the pre-confirm hook. A team whose design system does not need any of those is carrying a JavaScript library, a build step and a package to replace a browser feature.

The third is that the package makes claims it cannot fully own. It describes itself as accessible and WAI-ARIA compliant, and it is built on a JavaScript library with that reputation, but accessibility is a property of the resulting interface rather than of the library, and a dialog that inherits the wrong colours, the wrong focus order or the wrong timing from a theme is not accessible no matter what the markup says. A team that has accessibility requirements has to check the rendered result, which is what the demo application is for.

The alternative for a team that wants the look without the framework integration is to use the underlying JavaScript library directly, which loses the Blade directive, the facade and the migration tooling, and keeps the part of the behaviour that actually matters, the dialog. The difference in approach is that this package is a Laravel-shaped product with a Laravel-shaped API, and a team that is happy with a script tag and a function call pays less for less integration.

## Conclusion

Laravel SweetAlert v8 fits a Laravel application that wants a styled confirmation dialog without writing JavaScript, that has a design system to match, and that has a frontend stack where Livewire or Inertia components need to raise alerts from PHP. It is the wrong choice for an application whose alerts are rare and simple, because the browser can do a native confirmation with no dependency at all, and it is the wrong choice for a team that cannot absorb a major rewrite, since v8.0.0 was published as a complete rewrite with its own migration command. Before upgrading, run `php artisan alert:upgrade --dry-run` and read the output, and check that the seven bundled themes and the ARIA behaviour match what your own interface already does, because a dialog library is a visible part of the product.

## FAQ

### How do I install Laravel SweetAlert?

With `composer require realrashid/sweet-alert` followed by `php artisan alert:install`, and then add the `@sweetAlert` Blade directive to your layout. Alerts are raised from a controller through the `RealRashid\SweetAlert\Facades\Alert` facade, or with the global `alert()` helper.

### How do I upgrade a Laravel SweetAlert v7 application to v8?

Run `php artisan alert:upgrade --dry-run` to see what would change before anything is written, then run the upgrade command. Version 8.0.0 was published as a complete rewrite, and the package ships a Laravel Boost guideline and skill so AI assistants write v8 code rather than v7.

### Does Laravel SweetAlert work with Livewire and Inertia?

Yes. Livewire v4 support is first class through a SweetAlertTrait that dispatches alerts as browser events, and Inertia.js support comes through the included middleware that shares alerts with a Vue or React frontend.

### What does the data-confirm attribute do in Laravel SweetAlert?

It is the guarded action feature: `data-confirm` asks the user for confirmation before any link or form goes through, and no JavaScript has to be written for it. The AlertDeck demo application exercises the guarded action attributes alongside the alerts themselves.

## Sources

- [License: MIT](https://github.com/realrashid/sweet-alert/blob/main/LICENSE)
- [Project website](https://realrashid.github.io/sweet-alert)
- [README](https://github.com/realrashid/sweet-alert/blob/main/README.md)
- [realrashid/sweet-alert on GitHub](https://github.com/realrashid/sweet-alert)
- [Releases](https://github.com/realrashid/sweet-alert/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/realrashid-sweet-alert