- What does the edvinaskrucas/notification package actually do?
- It flashes typed messages such as success, error, info and warning, plus any custom types you configure, into the Laravel session and renders them through Blade templates on the next request. NotificationManager is a thin service layer over the session store and the Blade view factory, so it solves the 'show a message after a redirect' case and little else. It ships no persistence layer, queue, event bus or migration. If you need durable, cross-device or asynchronous notifications, this is not the package for that.
- How do I install edvinaskrucas/notification in Laravel?
- Run composer require edvinaskrucas/notification; on Laravel 5.5 and later auto-discovery registers the service provider and facade, so no manual wiring is needed. Then run php artisan vendor:publish to expose the config file and Blade views for theming. A working integration is realistically a couple of hours, most of it spent styling templates and choosing where to place the render call in your layout. Be aware that on Laravel 6 and above Composer will usually fail constraint resolution because the package targets illuminate/* 5.x.
- How do I display the notifications in my Blade layout?
- Add a single include or a Notification::showAll() call in your layout, usually near the top of the content area, so flashed messages render on the following request. The output comes from the published Blade views, which you can restyle to match your design system. Because rendering happens at view time, the session is read and cleared as part of the normal request lifecycle.
- Is edvinaskrucas/notification compatible with Laravel 6, 8, 10 or 11?
- The last release is from March 2017 and its Composer constraints target illuminate/* 5.x, so composer require normally fails at dependency resolution on Laravel 6 and above rather than at runtime. The session and view APIs it relies on have stayed stable, so a fork with widened constraints often works, but treat that as an assumption to spike rather than a plan. The 2017 code also predates PHP 8.x and may emit deprecations. If you must keep it, vendor it into your own packages directory or a private repository, widen the constraints, and add a CI job on your target PHP and Laravel versions.
- Does this package store notifications in a database?
- No. Notifications live in the session only: they are flushed on one request and read on the next, with no table, model, migration or read/unread state. That makes it unsuitable for notification feeds, inboxes, or anything that must survive a session or appear on another device. If you need persistence, use Laravel's built-in database notifications or a dedicated maintained package instead.
- Can I add custom notification types or override the templates?
- Yes. The config file lets you define additional types alongside the built-in success, error, info and warning, and the publishable Blade views can be edited or overridden to change markup and CSS classes. Custom types are simply extra keys the manager collects and the view iterates over. Keep your overrides in your own views directory where possible so future package changes do not clobber them.
- Can I use it in an API, SPA or Inertia application?
- Not really. The package is built around session state and server-rendered Blade output, so a JSON API, SPA or Inertia flow has no session flash to read on the next request in the way the package expects. For those stacks, return messages in your JSON payload or use your front-end toast system. This package is a fit only for server-rendered, session-backed Laravel monoliths.
- Is edvinaskrucas/notification still maintained?
- Effectively no. The most recent release is 2017-03-27 and there is no ongoing maintenance, so any framework break, PHP deprecation or security issue becomes yours to fix. The codebase is small, only a few hundred lines, which makes forking or reimplementing it cheap. Decide up front who owns the fork and what would trigger replacing it.
- Are there security or session driver concerns in production?
- Audit the default Blade templates for escaping if message content can ever include user input, since unescaped output is the obvious risk in a flash-message layer. The session driver also matters: the cookie driver has a roughly 4 KB ceiling, while Redis or database sessions fail differently under load or eviction. Localization and ARIA live regions are not provided, so plan to add them yourself if accessibility is a requirement.
- What are the alternatives if I want to replace it?
- The cheapest path is to reimplement the small manager plus a Blade component, or adopt a maintained toast or notification package, and keep a thin shim with the same Notification::success(...) facade signature so existing call sites keep compiling. Laravel's own session flash API covers the simplest cases with no dependency at all. For anything needing persistence, read state or asynchronous delivery, use Laravel's built-in notification system or a maintained alternative. Either route usually removes an unmaintained dependency without touching existing call sites.