Filament Notification Center Laravel Package

Product Decisions This Supports

• Build vs. buy for in-app notifications: this package targets the "notification center / inbox" surface of a Filament admin panel (persisted notifications, read/unread state, a UI to browse them). The decision it informs is whether to hand-roll that inbox — notification model, migration, read-state tracking, Filament page/resource, and the polling or broadcast plumbing — or adopt a maintained plugin. For most teams the answer is buy: this is commodity UI with low differentiation and non-trivial edge cases (per-user scoping, multi-panel behavior, unread counts).
• Admin/staff-facing engagement scope: an in-app notification center is a retention and workflow feature, not a customer-facing one. It supports roadmap items like "operators see system alerts and approvals in-product instead of email," and lets you defer investing in email/push infrastructure for internal users.
• Platform-version gating: the release formalises a PHP 8.3 minimum (the previous ^8.2 constraint was never actually resolvable — Filament v5 requires Livewire ^4.1, and the Pest Livewire tooling that supports Livewire v4 requires PHP ^8.3). This makes the package a direct input to your upgrade sequencing: if any production host is still on PHP 8.2, adopting this package is blocked until that host moves. Treat it as evidence for the "PHP 8.3+ everywhere" roadmap item rather than a surprise.
• Ecosystem lock-in assessment: adopting this pins you to the Filament v5 / Livewire v4 line. That's a legitimate roadmap constraint to weigh in the same breath as the build-vs-buy call, since it dictates when you can take Filament majors.
• Not a decision driver: v1.1.0 ships no behavior changes. CI and README-badge repairs plus the version-constraint correction are maintainer hygiene. They improve confidence in the project's health (the suite now actually runs, rather than aborting at bootstrap under PHPUnit 12's coverage-driver check) but add no capability and change no API.

When to Consider This Package

Adopt when:

• You're on Filament v5 with Livewire v4 and PHP 8.3+ already, or the 8.3 move is already scheduled and funded.
• You need a staff/admin inbox — persisted notifications with read state rendered inside the panel — and would otherwise spend a sprint building the model, migration, policy/scoping, and UI.
• You want the notification center to live natively in the Filament navigation rather than as a bolt-on page.
• You value a package whose test suite demonstrably executes: the v1.1.0 CI fix means green builds now mean something, which is a better signal than v1.0.1 offered.

Look elsewhere or build in-house when:

• You're on PHP 8.2 in production or CI. Adoption fails at composer require today; this is a hard blocker, not a warning.
• You're on Filament v3/v4 or Livewire v3. The dependency chain here is Filament v5 / Livewire ^4.1, so you'd need a different package or a fork.
• You need multi-channel delivery (email, SMS, push, digesting) or templating/localisation of notification content. An in-panel center is one surface; if your requirement is a notification platform, this is a component of it, not the whole answer.
• You need real-time delivery at scale (broadcast/websockets, high fan-out) — verify the package's transport story against your expected volume before committing, as the release notes give no signal either way.
• Licence, maintenance cadence, or bus-factor are unacceptable for a dependency sitting in your admin auth surface. One maintainer with a single repo and a two-release history is a real risk to price in; check the licence and issue responsiveness directly.

How to Pitch It (Stakeholders)

To executives: We're evaluating a small open-source plugin that adds a notification inbox to our admin panel — the place staff see system alerts, approvals, and status changes without leaving the product. It replaces roughly a sprint of in-house work on a low-differentiation UI. The cost is a platform floor: it requires PHP 8.3, which is where we're headed anyway, so this is a sequencing question rather than new spend. No customer-facing changes and no new vendor contract.

To engineering: This is prodstarter/filament-notification-center v1.1.0. No API changes and no behavior changes since v1.0.1 — the release is CI and docs hygiene plus a corrected PHP constraint. The one substantive fact: the declared ^8.2 was never installable (Filament v5 → Livewire ^4.1 → Pest Livewire tooling → PHP ^8.3), so the floor is now honestly ^8.3. Practical reads: (1) don't attempt adoption on any 8.2 image, it won't resolve; (2) the previous green-ish CI was misleading — the suite was aborting at PHPUnit 12 bootstrap on a missing coverage driver with failOnWarning="true", so v1.1.0 is the first release where a passing build means tests actually ran; (3) adopt only if we're committed to Filament v5 / Livewire v4, since this pins us there. Before we adopt, someone should review the notification model design, per-user scoping, and how read-state is queried at volume — the release notes tell us nothing about runtime behavior.