Notification Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for notifications: The evidence points decisively to build on native, not buy/adopt. Notifications are a solved problem in Laravel's first-party Notifications API; paying integration cost for a dormant third-party abstraction is a negative-value trade.
• Framework-fit gate: The package is a Symfony2 bundle, not a Laravel package. Any roadmap item that assumes drop-in adoption should be re-scoped immediately — this is a hard stop, not a porting exercise.
• Legacy estate triage: If any team still runs Symfony 2.x, the real decision this surfaces is migrate off the platform, not add this bundle. Symfony2 reached end-of-life in 2018; the bundle is a symptom, not a solution.
• Roadmap confidence for notification features: In-app feeds, multi-channel delivery, read/unread state, digest batching — all are achievable on Laravel primitives in days. This package should not appear as a dependency in any feature estimate.
• Risk register entry: 4 stars, 0 dependents, score 0.11, no visible security process. This is a "do not evaluate further" signal for dependency and security review shortlists.
• Design reference, narrowly: The domain model (notification entity, notifier-per-channel abstraction, recipient resolution) can inform an internal schema design spike. Value is illustrative only — Laravel shipped equivalent patterns natively in 5.3.

When to Consider This Package

• Only when maintaining an existing Symfony 2.x application that already depends on this bundle and the work is limited to bug-fixing or preserving current behavior.
• As a reading reference for engineers designing a notification domain model — channel abstraction, notification records, read-state, recipient resolution. Inspiration, not a dependency.
• Look elsewhere when:
  • You are on Laravel — use the native Notifications API (Notifiable trait, via(), mail/database/broadcast channels, queue integration). First-party, maintained, free, PHP 8 compatible.
  • You are on modern Symfony — use symfony/notifier (5.3+) or a maintained bundle. Do not inherit Symfony2-era code.
  • You require security patching, LTS, community support, or PHP 8 / Laravel 10–11 compatibility — none of which this package offers.
  • You need vendor accountability or SLAs — zero dependents means no one is on the hook.
  • You need queued, retryable, observable delivery — the bundle's era assumes synchronous sends on the request path.

How to Pitch It (Stakeholders)

For executives (bottom line): Do not adopt this package. It is a Symfony2 bundle — a framework generation that has been end-of-life since 2018 — and it does not target Laravel at all. With 4 GitHub stars and zero dependent projects, there is no community, no maintenance signal, and no security response process. Adopting it would mean bridging EOL components into a modern Laravel application, inheriting transitive vulnerability risk, and owning the fork forever, in exchange for zero differentiated capability. Our notification needs are already covered by first-party, framework-maintained tooling. Recommendation: treat it as reference material only; fund the notification feature through Laravel's native Notifications API or a small internal abstraction we control.

For engineering: The package attacks a legitimate problem space — multi-channel notification modeling, persistence, and delivery — but its implementation is bound to Symfony2's container, Doctrine ORM, and event dispatcher. There is no ServiceProvider, no facade, no publishable config, and no Laravel-aware mail or queue integration; Composer will not resolve it cleanly into a PHP 8.2+ app. The useful path is to read its notifier-per-channel and entity patterns, extract any non-obvious routing or batching rules as explicit service classes behind an interface, and rebuild them on Notifiable, via(), and ShouldQueue with Horizon for retry and per-channel concurrency. Budget days, not weeks. Do not sequence this as "add the dependency, then adapt" — that ordering inverts the risk. The right sequence is a 1–2 day spike to produce a gap list, a decision gate, then a short prototype with tests pinning behavior. The learning investment should go into our own Laravel notification and queue internals, where the knowledge compounds across every future feature, rather than into Symfony2 code we intend to discard.