Notification Bundle Laravel Package

Product Decisions This Supports

Framework reality check up front: despite being filed under "Laravel/PHP," this is a Symfony bundle, not a Laravel package — and 4.0 does not change that. It will not drop into a Laravel app. It is useful to a PM as (a) a build-vs-buy input for a legacy Symfony codebase, or (b) a reference design for what a notification inbox needs. Every decision below assumes one of those two framings.

• Ship an in-app notification center in v1, or defer it. The bundle supplies the persisted model most teams end up writing by hand: a notification entity, a notifiable-entity linkage (trait + interface on your User/Account entity), read/unread ("seen") state, timestamps, and a manager service to create, fetch, paginate, mark-as-read, and delete. That collapses the backend estimate from roughly 1–2 sprint-weeks to integration work.
• Build vs buy for notification persistence. The alternative is your own Doctrine table + repository + service + a thin JSON controller. That is on the order of a few hundred lines. Buying it converts an engineering cost into a maintenance liability; owning it converts a time cost into control. 4.0 slightly improves the buy case — a cleaner extension point for a custom Notification entity means you can own your domain model while still reusing the inbox mechanics — but the maintenance liability is now more concrete, not less (see the upgrade cost below).
• Force the notification schema decisions early. Adopting the bundle's model commits you to per-user rows, per-notification seen flags, and soft-delete semantics. Those are product decisions (Do users get a single inbox or per-category inboxes? Is "read" the same as "dismissed"? Do notifications expire?) that this package makes visible and cheap to prototype — arguably its highest-value use even if you never ship it.
• Decide the notification-content trust model now. 4.0 re-enables HTML rendering in the notification list. That is a product decision as much as a technical one: if notification bodies are authored by trusted internal staff or generated from templates we control, HTML rendering is a feature (rich formatting, links, emphasis). If any notification body can contain user- or third-party-supplied text, this is an XSS surface and you must sanitize on write or render. Do not let this be settled by a dependency bump.
• Separate "inbox" from "delivery." The bundle handles persistence and retrieval only. It does not orchestrate email, SMS, or push, and has no real-time channel. That separation is useful for roadmap sequencing: ship the in-app inbox first, add email digests and push as independent follow-on epics.
• Legacy Symfony 3 maintenance calls. If you have an SF3 app in keep-the-lights-on mode and a framework upgrade is not funded, this is a low-cost way to add notifications without a migration project. 4.0's renewed activity marginally improves the optics of this call, though it does not change the underlying risk profile.
• Not a decision it supports: anything Laravel-shaped. For a Laravel codebase the equivalent decision is settled by the framework's first-party Notifiable trait and database notification channel, which is maintained, documented, and already in your dependency tree.

When to Consider This Package

Adopt (vendor, don't just install) when:

• You are on Symfony 3.x — realistically 3.4 — and have no near-term upgrade plan. The bundle's Doctrine mappings, service configuration, and annotation style target that era; 4.0 fixes and extends within that era, and does not signal a move to newer Symfony.
• You need DB-backed, per-user, read/unread notifications — an inbox — and not real-time delivery.
• Your notifiable subjects are Doctrine entities and you control their schema, so adding a trait/interface is acceptable.
• You want a custom Notification entity. This is materially easier after 4.0: entity overriding is fixed and configured through mgilet_notification.notification_class rather than Doctrine resolve_target_entities, and NotificationManager::createNotification now returns your custom class instead of a base entity — which removes the type-juggling most teams would otherwise write around.
• Notification volume is modest and you can tolerate forking and owning the code.
• You want a working prototype fast to validate the inbox UX before committing to a real build.

Look elsewhere when:

• You are on Laravel. Use the framework's database notification channel (plus a UI layer such as a Filament or Inertia/Vue notification component). There is no code reuse here.
• You are on Symfony 5/6/7. Use Symfony Notifier for multi-channel delivery, paired with Mercure or UX Turbo for live updates, or an actively maintained third-party bundle.
• You need transport fan-out — email, SMS, push, templating, localization, per-user channel preferences, digest batching. None of that is in scope here.
• You need delivery guarantees — queuing, retries, dead-letter handling, idempotency.
• Scale is material. No evident story for partitioning, archival, or bulk insert; a naive per-row notification table becomes a problem in the tens of millions of rows.
• You need maintenance assurance. 4.0 is a genuine signal of life — two community fixes merged, one of them a multi-year-old bug (HTML rendering broken since 3.2) — but the fundamentals are unchanged: effectively a single-maintainer project, no credible security-response path, and no evidence of production validation at scale. One release after a long gap is a data point, not a track record.

Migration cost if you already run 3.x: 4.0 is a breaking change for anyone using a custom Notification entity. You must remove the resolve_target_entities Doctrine directive and add config/packages/mgilet_notification.yaml with notification_class. Small in isolation, but plan it rather than absorbing it — and if you followed the earlier advice and forked, this is a rebase you have to schedule.

Decision rule: if you are not on Symfony 3, do not adopt — read the source for schema ideas and move on. If you are on Symfony 3, treat it as a starting point to fork, not a dependency to trust. If you already forked on 3.x, take 4.0's custom-entity fix and HTML fix as patch material, and re-check your sanitization assumptions before enabling HTML output.

How to Pitch It (Stakeholders)

To executives: This is a small MIT-licensed Symfony library that provides a user notification inbox out of the box — the database model, read/unread tracking, and the service layer to create and fetch notifications. It removes an estimated one to two weeks of backend work and lets us spend that time on the inbox UI and on the notification content itself, which is where users actually form an opinion. Version 4.0 shipped recently with two community bug fixes, including a long-standing HTML-rendering defect, and a cleaner way to plug in our own notification entity — modest but real evidence the project is not dead. The honest caveats remain: it applies only if we stay on Symfony 3, it is still a single-maintainer project with a long release gap and no downstream projects depending on it, and 4.0 is a breaking change for anyone already using a custom entity. My recommendation is unchanged: treat it as a fork we own, or as a reference design if we are on Laravel or a newer Symfony, where the platform already gives us this capability for free.

To engineering: Do not install-and-forget. Vendor or fork it, pin the version, audit the Doctrine schema and service definitions, and add tests around the notification manager — especially seen/unread transitions and deletion, which is where inbox bugs surface. If you are upgrading from 3.x with a custom entity, budget for the 4.0 migration: drop resolve_target_entities from Doctrine config, add mgilet_notification.yaml with notification_class, and verify createNotification now returns your entity (that fix is the reason to upgrade, but confirm your type hints and factories agree). Separately, treat the re-enabled HTML rendering as a security review item, not a changelog line: confirm notification bodies are sanitized or that only trusted content reaches the renderer. Accept that you own the upgrade path for as long as the feature lives. The counter-proposal is to write our own entity, repository, service, and endpoint: a few hundred lines, more upfront effort, but fully ours and consistent with our conventions and framework version.

To design/product: The bundle's data model is a useful forcing function — it makes us answer whether read and dismissed are the same thing, whether notifications expire, and whether the inbox is global or per-category. 4.0 restores rich HTML in the notification list, which is a design opportunity (links, formatting, richer actions) and a content-governance question (who is allowed to author markup in a notification). Prototype the UX against it before we commit to building or buying anything heavier.