Weave Code
Alerts Laravel Package
laragear/alerts
Laragear Alerts is a Laravel package for adding persistent, database-backed alerts to your app. Define targeted announcements, schedule when they appear, and track read or dismissed status with a simple API—ideal for in-app notices and user messages.
Set multiple alerts from your backend, render them in the frontend.
Frequently asked questions about Alerts
- How do I install laragear/alerts in a Laravel application?
- Install it with composer require laragear/alerts. Laravel package auto-discovery registers the service provider, and you will typically publish the config and view stub and add the Blade component or directive to your base layout. The wiring is small; most of the work is aligning the markup with your design system. Check the tagged release's composer.json before scheduling the upgrade.
- Which Laravel and PHP versions does laragear/alerts support?
- The package targets PHP 8.x and a current Laravel release with Blade, but you must confirm the exact constraint in composer.json against your pinned framework. The assessment flags an anomalous last-release date, so verify the actual tagged version and its Laravel/PHP support matrix rather than trusting the listing. Compatibility risk is concentrated in Laravel major upgrades and Blade or session changes.
- Does laragear/alerts work with Livewire and Inertia?
- Blade and Livewire are the natural fit because alerts are set before redirect and rendered from the session on the next request. Inertia can work if you expose the alert bag as a shared prop through HandleInertiaRequests and let Vue or React own rendering, but that adapter is extra scoped work. API-only and SPA backends without a shared session are a poor fit.
- How do I set an alert from a Laravel controller before redirecting?
- Call the Laragear Alerts facade in your controller or service before returning a redirect. The package is built around post-redirect-get flows, so the alert is collected server-side and rendered by the Blade component in your layout on the next page load. Standardize on the facade as the single entry point so you do not end up with parallel flash conventions.
- Is laragear/alerts accessible by default, and can I customize the alert markup?
- The package ships a ready-made renderer, and views are expected to be publishable so you can override markup and classes for your design system. Confirm the shipped ARIA roles, dismiss semantics, focus behavior, and whether raw HTML in messages is allowed before you treat it as accessible or XSS-safe by default. Custom alert types and levels should be validated against the tagged release, since the documented taxonomy is success, error, warning, and info.
- Is laragear/alerts production-ready and actively maintained?
- It is a thin, low-risk abstraction, but adoption is small at roughly 41 stars and provenance is a single maintainer, so bus-factor is the real concern. Because the API surface is small, an in-house fork or replacement is typically a one-to-two-day effort. Treat governance and release cadence as the production gate, not the code complexity.
- What is the difference between laragear/alerts and Laravel session flash messages or toast libraries?
- It overlaps with session()->flash() partials and JavaScript toast libraries; the value is a consistent success/error/warning/info taxonomy, one facade, and a ready-made renderer rather than new capability. The common failure mode is running it alongside an existing toast or flash convention, which produces duplicate or divergent UX. Inventory existing alerts and migrate flow by flow.
- Does laragear/alerts persist alerts in the database and track read or dismissed status?
- The package blurb advertises persistent, database-backed alerts with read or dismissed tracking, while the technical assessment describes it as a session-flash-oriented presentation-layer package with no persistence layer. Those statements conflict, so inspect the tagged release for migrations, models, and read/dismissed columns before relying on database persistence. If persistence matters, confirm it in a spike before committing.
- How do I test laragear/alerts in Laravel feature tests?
- In feature tests, assert that your controller sets the expected alert before redirect and then follow the redirect and assert the rendered markup or session payload. Keep assertions on semantic output and alert type rather than brittle CSS classes, and cover dismissal or read behavior separately if the package persists it. For Inertia, assert the shared alert prop instead of HTML.
- Can I use laragear/alerts in an API-only or SPA backend?
- An API-only or SPA backend without a shared session is a poor fit because the package assumes server-rendered flows. You would need to layer a transport on top, such as a JSON envelope or response header, and let the client render it. Scope that adapter explicitly or choose a client-side notification library instead.
Weaver
How can I help you explore Laravel packages today?