Alertify Bundle Laravel Package

Getting Started

Reality check first: troopers/alertify-bundle is a Symfony bundle, not a Laravel package. It wraps the (very old) alertify.js 0.4.x library, hooks into Symfony's session flash bag, and exposes a Twig extension that dumps queued notifications into the page. There is no AlertifyServiceProvider, no facade, no config publish tag. composer require troopers/alertify-bundle in a Laravel app will drag Symfony's HttpKernel, DependencyInjection, and Twig bridge into your vendor/ for zero runtime benefit.

So the pragmatic "getting started" is: steal the pattern, not the dependency.

1. Look at the repo's Resources/ directory — config/, views/ (the Twig partial with the alertify.xxx(...) calls), and the Twig extension class. That's the whole package; it's ~200 lines of glue.
2. Install the modern JS equivalent in your Laravel app instead:

npm install alertifyjs   # note: alertifyjs 1.x, not alertify.js 0.4

3. Import once in resources/js/app.js:

import 'alertifyjs/build/css/alertify.min.css';
import 'alertifyjs/build/css/themes/default.min.css';
import alertify from 'alertifyjs';
window.alertify = alertify;

4. Create the Laravel equivalent of the bundle's flash-bag bridge — a Blade partial in your layout, right before </body>:

{{-- resources/views/partials/notifications.blade.php --}}
@php
    $types = ['success', 'error' => 'error', 'warning', 'message' => 'message'];
    $bag = [];
    foreach (['success','error','warning','info'] as $type) {
        foreach (session()->pull("alertify.$type", []) as $msg) {
            $bag[] = ['type' => $type === 'info' ? 'message' : $type, 'text' => $msg];
        }
    }
@endphp
@if($bag)
<script>
    window.__alertifyQueue = @json($bag);
</script>
@endif

5. First use case: PRG (post/redirect/get) feedback on a form submit.

return redirect()->route('posts.index')
    ->with('alertify.success', 'Post created.');

If you are maintaining a Symfony app alongside this Laravel work: register the bundle in config/bundles.php, import @Alertify/alertify.html.twig in your base layout, and call alertify.success() from your controller via the session flash bag. That's the whole install.

Implementation Patterns

One render point, many producers. The bundle's core idea is worth copying: controllers never touch JavaScript. They push to a session keyed queue; a single layout partial drains it. Keep that discipline so a notification can be added from a controller, a job, a middleware, or a listener.

Wrap the flash calls in a helper so you're not typing string keys everywhere and can swap the transport later:

// app/Support/Notify.php
class Notify
{
    public static function success(string $m): void { session()->push('alertify.success', $m); }
    public static function error(string $m): void   { session()->push('alertify.error', $m); }
}

session()->push() (not ->with()) matters — it stacks multiple messages per type so a validation block can report several errors.

Mirror the bundle's config knobs in a config file. The Symfony bundle's Configuration.php exposes delay, position, theme, dismissButton, clickToClose, etc. Translate those to config/alertify.php and inject them as a single JS object, not as scattered inline calls:

<script>
    alertify.defaults = @json(config('alertify.defaults'));
    (window.__alertifyQueue || []).forEach(n => alertify[n.type](n.text));
</script>

AJAX / Inertia / Livewire. The flash-bag trick breaks down when there's no full page load, because the partial never re-renders. Two patterns work:

• Inertia: share notifications via HandleInertiaRequests::share(), then fire them in a router.on('finish')/useEffect hook on the front end.
• Plain fetch: return them in the JSON body ({"data": ..., "notifications": [...]}) or as an X-Notifications header, and let a global fetch wrapper call alertify.notify(...).

Queue after commit. Notifications tied to a DB write should be pushed after DB::afterCommit() / after the job succeeds, otherwise a rolled-back transaction leaves a cheerful "Saved!" toast on screen.

Testing. Assert the queue rather than the HTML:

$response->assertSessionHas('alertify.success', 'Post created.');

And one feature test that asserts the partial renders a <script> block when the session is seeded — that catches the "partial got removed from the layout" regression, which is the most common way this silently stops working.

Styling. The default alertify theme is dated. Override .ajs-* classes in your own CSS rather than forking the vendor stylesheet; keep the overrides in a separate file so an npm update doesn't clobber them.

Gotchas and Tips

• Two different libraries share a similar name. alertify.js 0.4 (what the bundle bundles) has alertify.success() / alertify.log() and .alertify-log CSS classes. alertifyjs 1.x has alertify.notify(msg, type) and .ajs-* classes. Copy-pasting snippets across versions produces silent no-ops. Pick one and stay there.
• The package is stale. Last release July 2020, 48 stars, zero dependents. Symfony 5-era at best; expect Class "Symfony\Component\DependencyInjection\Extension\Extension" not found-style breakage on modern Symfony, and definitely do not try to boot it in Laravel.
• Read-once flash semantics. If your layout partial renders twice — double @include, an error page plus the main layout, an exception renderer — you'll get duplicates or lose messages. Drain with session()->pull() exactly once, in one place. This is the #1 debugging session for this pattern.
• XSS via message text. The bundle injects message strings straight into a <script> block. In your port, always go through @json(...) or json_encode(..., JSON_HEX_TAG|JSON_HEX_AMP). Never {!! $message !!} inside the JS.
• alertify is not defined almost always means the CDN/asset import lives after the inline queue script, or Vite hasn't bundled it. Check script order in the rendered HTML before touching config.
• Config caching. Symfony's alertify: config is compiled into the container — bin/console cache:clear after every change, or you'll swear the delay setting is ignored. Laravel equivalent: php artisan config:clear, and remember config('alertify.*') returns null in @json if the key is missing (producing {}, not an error — easy to miss).
• SPA/Turbo navigation wipes the container. alertify mounts into document.body; Turbo/Livewire DOM swaps can orphan the node or drop queued messages. Re-initialize on turbo:load / Livewire.hook('message.processed') if you use either.
• Don't toast every event. Once notifications are one line of code, they multiply. Throttle or aggregate (e.g. "3 items imported") — the bundle gives you no rate limiting, and neither will your port.
• Extension points worth keeping: an adapter interface (Notifier with a ToastNotifier, SweetAlertNotifier, NullNotifier for tests) and a single Blade partial you can swap wholesale. That's what makes this pattern survive contact with a real app; it's also the piece the bundle never exposed cleanly, which is why it's easier to reimplement than to integrate.