Notifications Filament Laravel Package

Technical Evaluation

Architecture fit This is a presentation adapter in a ports-and-adapters arrangement: a notifications domain module (liberusoftware/module-notifications) exposed through Filament UI. That is a defensible seam — the adapter should contain Livewire components, Blade views, a notification page/bell, and translation/navigation registration, with domain logic remaining in the core module. It presupposes a modular monolith already composed of liberusoftware modules and a Filament panel. If we are not already on that module family, the package has near-zero standalone value.

Integration feasibility Mechanically simple: composer require, register the plugin/provider on a Filament panel, publish config/views. Substantively unproven: 0 stars and 0 dependents means no public evidence of anyone installing this against a real Laravel/Filament version matrix. We would be the first integrator and would absorb all undocumented prerequisites, including the parent module's contract shape.

Technical risk

• License is the gating risk. NOASSERTION means GitHub could not identify an SPDX license. This is a legal blocker, not a footnote — it may be proprietary, malformed MIT, or a custom header. No production or customer-facing deployment until counsel clears it.
• Bus factor 1. Single vendor, single maintainer, no community. Abandonment is the base case, not the tail case.
• Filament major-version coupling. Filament ships breaking changes between majors; a thin adapter will break first and loudest on upgrade.
• Release provenance. A 2026-10-26 release date is ahead of the current date; verify whether this is a misconfigured system clock, a future-dated tag, or a signed release. Confirm tags are immutable and signed.
• Value-add is unproven. Filament already ships database notifications (bell + notifications page). The adapter's marginal value is only the bridge to the liberusoftware domain model — that must be confirmed, not assumed.
• Mitigating factor: presentation adapters are small. A few hundred lines of Blade/Livewire is cheap to fork and own.

Key questions

1. Which Filament major and which Laravel/PHP versions are supported, and is that constraint set tested in CI?
2. What is the license, in writing, and is it compatible with our distribution model?
3. Is module-notifications open source, maintained on the same cadence, and does it publish a stable contract (DTOs/interfaces)?
4. Does the adapter contain any business logic that should live in the domain module?
5. What is the fork cost — LOC count, view count, test coverage?

Integration Approach

Stack fit Laravel + Filament (TALL). Fits only if Filament is already our admin surface. This is not a general notification UI and provides nothing to a non-Filament app.

Migration path Adopt in dependency order: domain module first, adapter second. The real migration work is not the adapter — it is reshaping our existing notification payloads into whatever contract the core module expects (likely a DTO/data object). If we currently use Laravel's native DatabaseNotification, plan a backfill or dual-write window for the notifications table.

Compatibility Pin Filament, Livewire, and Laravel constraints explicitly in composer.json before the spike. Run the initial evaluation in a throwaway branch against a single non-critical panel. Expect to discover undocumented requirements — with zero dependents there is no prior art to borrow.

Sequencing

1. Legal review of the license (hard gate; do not parallelize).
2. Spike: install parent module + adapter in a sandbox panel; verify bell, page, read/unread, and fan-out.
3. Contract test: drive a real domain event through to a rendered notification.
4. Decide depend-vs-fork. Given 0 dependents, default to vendoring the adapter under our namespace with a patch layer.
5. Roll out to an internal admin panel only. Do not put this in front of customers in phase one.

Operational Impact

Maintenance Treat upstream as unmaintained and budget accordingly: ~1–2 engineer-days per quarter, concentrated on Filament major upgrades. Keep a thin fork or a Composer patch so we are never blocked on an upstream PR that will not be reviewed.

Support No issue history, no community corpus, no vendor SLA. Support means reading the source. Acceptable precisely because the surface is small; unacceptable if the parent module turns out to be large and equally orphaned.

Scaling This is a presentation layer, so horizontal scaling follows the Filament panel. Two real concerns: (a) unbounded growth of the notifications table — retention/pruning must live in the core module and must be verified, not assumed; (b) bell refresh strategy — confirm whether it polls or uses broadcasting. Polling across a large admin user base is a database load problem that will be attributed to this package.

Failure modes

• Filament major bump breaks Livewire/Blade APIs silently.
• Parent module contract change with no semver signal → runtime type errors.
• View/namespace collisions in multi-panel Filament installs.
• N+1 queries if the adapter resolves notifications per-user without eager loading.
• License clarified restrictively after we have shipped — a re-licensing risk we cannot control.

Ramp-up Low for a Filament-fluent engineer (hours to first render), but onboarding cost is front-loaded onto whoever performs the spike, because there is no documentation to inherit. Capture findings as internal docs during the spike; that artifact is the actual deliverable.

TPM recommendation Do not adopt on the strength of this package. Evaluate module-notifications as the real decision; this adapter is a cheap, forkable convenience if and only if the parent module is credible and the license clears. If the parent is similarly single-vendor and unstarred, build the Filament notification surface in-house against Filament's native database notifications — the incremental effort is small and the ownership risk drops to zero.