Alertify Bundle Laravel Package

Getting Started

First, reality-check the target framework. Despite the Laravel framing, this is a Symfony bundle (namespace AvAlertify), and with 0 stars / 0 dependents it is almost certainly an unmaintained scaffold — likely Symfony 2.x/3.x era. Before writing a line of app code, open the repo and read four files in this order:

1. composer.json — check symfony/symfony or symfony/framework-bundle constraint. If it pins ^2.8 or ^3.0, it will not install on Symfony 5/6/7 without a fork.
2. AvAlertifyBundle.php — confirms the bundle class name and any compiler passes.
3. DependencyInjection/Configuration.php — the only reliable source of config keys. There is no README worth trusting.
4. Resources/views/ and Twig/ — tells you what Twig helpers and templates actually ship.

Install (Symfony ≤4):

composer require pdfloresjdav/alertify-bundle

Register the bundle:

// Symfony 3/4: app/AppKernel.php
$bundles = [ new Av\AlertifyBundle\AvAlertifyBundle() ];
// Symfony 4+ Flex: config/bundles.php
Av\AlertifyBundle\AvAlertifyBundle::class => ['all' => true],

Then, and only if the bundle ships an AlertifyInterface/service, wire your first use case: flash messages → Alertify toasts. That is the 80% use case and the one worth validating before anything else:

$this->addFlash('success', 'Client saved.');

…rendered by the bundle's Twig block, or by your own layout include if the bundle ships no block.

If the bundle exposes nothing usable after that read-through, stop and use AlertifyJS directly — vendor the JS/CSS via assets/ and skip the bundle. For a Laravel developer: this bundle is the rough equivalent of a laravel-flash-style package that ships a Blade component plus config — except here you may have to rebuild the Blade component yourself.

Implementation Patterns

Pattern 1 — Flash-message rendering in the base layout. Keep the mapping in one place. If the bundle doesn't provide it, write a Twig macro that walks app.flashes and emits alertify.success(...) / alertify.error(...) calls in a single inline <script> at the end of <body>:

{% for type, messages in app.flashes %}
  {% for message in messages %}
    <script>alertify.{{ type == 'error' ? 'error' : 'success' }}({{ message|json_encode|raw }});</script>
  {% endfor %}
{% endfor %}

|json_encode|raw is mandatory — never interpolate a message into a JS string literal raw.

Pattern 2 — Service injection over Twig globals. If the bundle registers a service (check Resources/config/services.yml for the id — usually something like av_alertify.manager), inject it into controllers rather than calling Twig helpers, so you can unit-test the message payloads without rendering.

Pattern 3 — AJAX/JSON bridge. The bundle's server-side helpers are useless for XHR responses. Standard workflow: controller returns JsonResponse(['alerts' => [['type' => 'success', 'text' => '...']]]), and a small JS handler (fetch/axios interceptor) funnels the array into alertify.notify(). Do not try to make the bundle's Twig layer do this.

Pattern 4 — Confirmation flows go client-side. alertify.confirm() is callback-based; there is no synchronous return. For delete buttons, attach the handler and use the callback to submit the form — the bundle cannot give you a blocking server-side confirm. Pair it with a POST route + CSRF token.

Pattern 5 — Config as a theming layer. Put theme/position/delay defaults in config/packages/av_alertify.yaml (or config.yml), expose them to JS via a data- attribute or a small window.ALERTIFY_CONFIG bootstrap, so front-end tweaks don't require touching PHP.

Gotchas and Tips

• Version compatibility is the whole ballgame. A Symfony 2/3 bundle will fail composer require on modern Symfony. Check the constraint first; if it's stale, either pin your app (bad idea) or fork the bundle and bump the constraint — the code is usually thin enough that it still works.
• Assetic. Older bundles reference {% javascripts %} / {% stylesheets %} tags. Assetic is gone from modern Symfony; these tags will throw. Replace with plain <script src="{{ asset(...) }}"> and move AlertifyJS into your asset pipeline (Webpack Encore / Vite).
• Bundle may not ship the AlertifyJS assets at all. Many of these wrappers only emit calls and assume you included the library. If alertify is not defined appears in console, that's your answer — add the CDN or npm asset yourself.
• Service ID guessing wastes time. Don't assume alertify.manager. Run php bin/console debug:container | grep -i alertify and php bin/console debug:twig | grep -i alertify — that tells you exactly what the bundle registered, or that it registered nothing.
• XSS. Every message path must be JSON-encoded. Alertify accepts HTML in messages; if any flash content is user-derived, escape it before it reaches the JS layer, not after.
• Toast stacking. Default alertify.set('notifier','delay', 5) plus rapid-fire flashes produces an overlapping pile. Set a small delay and cap emitted messages (e.g. collapse duplicates) in your macro.
• Config quirks. Symfony bundle config keys are frequently undocumented or mismatched between Configuration.php and the Twig template reading them. Validate with php bin/console config:dump-reference av_alertify (adjust the root alias from Configuration.php).
• Extension points are the escape hatch. If the bundle's Twig extension is final or its service is private, you can still override the shipped template by placing a file at the same path under templates/bundles/AvAlertifyBundle/... — standard Symfony bundle override. That's usually faster than forking.
• Don't build a dependency on it. With 0 dependents and 0 stars, treat this as a stopgap: isolate every call behind your own one-file Notifier service or Twig macro. When (not if) you replace the bundle, you change one file.