- How do I install caiquebispo/notification-bell in a Laravel app?
- Install it with Composer using composer require caiquebispo/notification-bell, then run php artisan migrate to create the package tables. The config file, migrations and views are publishable, but publishing is optional because the package ships self-contained assets. Finally drop the Livewire bell component into your layout, typically inside the header. There is no npm install or asset build step required.
- Does this package work with Laravel's built-in notification system?
- No. It is a parallel notification subsystem with its own tables, helper class and HasNotifications trait, and it does not emit or consume Illuminate\Notifications\Notification objects or channels by default. Adopting it means either running two notification systems side by side or standardizing on this one and giving up Laravel's mail, database and broadcast channel machinery. You also lose ecosystem tooling such as Notification::fake() test helpers and per-channel preferences. Evaluate that architectural trade-off before committing.
- Which Livewire version does notification-bell support, v2 or v3?
- The README references @livewireScripts and a polling syntax that can differ between Livewire v2 and v3, and the component APIs are not identical across those majors. Verify the supported version on day one rather than mid-sprint, because component lifecycle hooks and polling behavior change between releases. Check the installed Livewire version in composer.json against the package constraints before installing.
- Do I need Tailwind, Alpine or an npm build to use the notification bell?
- No. The package ships self-contained CSS prefixed with nb- served directly from vendor through a package route, so it works in Tailwind, Bootstrap or plain CSS projects without vendor:publish. There is no npm run build step and nothing to compile. That said, the frontend surface is still opinionated about Livewire and Alpine, so teams on Inertia, Vue or Blade-only stacks should test it early.
- Will this package conflict with Alpine.js that Livewire already bundles?
- It can if you follow the README literally. Livewire already ships Alpine, and the docs tell you to add a second Alpine via CDN if it is not already in use, which causes duplicate-instance initialization bugs on a standard Livewire app. Only include one Alpine instance, and confirm the package's scripts work with the bundled version. This is the most common documentation trap for junior developers in this package.
- How are in-app notifications delivered, polling or web sockets?
- Delivery is polling by default, with a configurable interval around ten seconds, and there is an optional broadcasting path that is disabled out of the box. That is fine for a header bell in a typical admin app, but it sets a ceiling on latency and volume. If you need real-time or high-throughput notifications, you would have to enable and verify the broadcasting path yourself.
- Is the notification admin panel safe to expose to all authenticated users?
- By default the routes, including the admin panel for creating, editing, deleting and broadcasting notifications, use the web and auth middleware only. That means any logged-in user could reach the admin screens unless you override route.middleware in the config with a role check, a gate or a policy. Treat this as the highest-priority hardening step before shipping. Do not deploy the panel until authorization is explicitly configured.
- Can I customize the user model, table names and route prefix?
- Yes, configurability is one of the package's stronger points. The config exposes the user model, table name, column mapping such as nome to name, route prefix, middleware and name, polling interval, notification types, cleanup retention and a broadcasting toggle. Because the package owns routes under a notifications prefix, including an admin panel at the same prefix, check for collisions with your existing /notifications routes and route names before installing. In regulated environments also note that migrations auto-load, so php artisan migrate will silently add tables.
- How do users mute categories, set quiet hours or enable dark mode?
- Each user manages their own experience through a preferences panel inside the bell. They can toggle popup toasts and sounds with volume control, mute notification categories individually, snooze with do-not-disturb for one, four, eight or twenty-four hours, and set daily quiet hours such as 22:00 to 08:00 including midnight-crossing ranges. Dark mode support assumes a class-based strategy, so your <html class="dark"> setup and Tailwind darkMode configuration need to align.
- Is caiquebispo/notification-bell production ready and actively maintained?
- Treat it cautiously. The repository shows bus factor one, zero dependents and only a couple of stars, with no stated CI or test suite and release notes that are empty Full Changelog links. Version history shows activity from 1.0.0 to 1.2.2, but you cannot risk-assess upgrades from changelogs and must diff tags instead. For critical applications, consider wrapping it behind your own abstraction or evaluating more established alternatives.