Notification Bundle Laravel Package

Technical Evaluation

Framework mismatch is still the headline risk, and 4.0 confirms it. The 4.0 release is unambiguously Symfony-native: the upgrade instructions require a YAML file at config/packages/mgilet_notification.yaml and removal of a Doctrine resolve_target_entities directive. Those are Symfony Flex recipe conventions and Doctrine bundle configuration — artifacts that have no meaning in a Laravel application. Nothing in 4.0 narrows the gap: no service provider, no facade, no config publish stub, no Eloquent mapping. The package remains non-installable in Laravel.

Architecture fit. Unchanged. The bundle's value is a domain model — a Notification entity attached to any "notifiable" entity via a join table, plus seen/unseen state and unseen-count helpers — tightly coupled to Doctrine entity mapping, Symfony DI compiler passes, and Twig rendering. 4.0 reinforces the coupling by making the notification class a first-class container configuration concern.

What 4.0 actually changes. This is a maintenance release, not a capability release. Two items:

1. HTML rendering in the notification list restored — a regression fix from 3.2. This is the single most consequential line for risk assessment: the bundle now renders stored notification content as HTML in the UI. Notification payloads frequently contain user-influenced or third-party-influenced strings. Restoring HTML rendering without a documented sanitization story reintroduces a stored-XSS surface that the 3.2 break had incidentally closed.
2. Custom notification entity support fixed — NotificationManager::createNotification now returns the custom class rather than a base entity. Useful for anyone extending the model, but it arrives with a breaking configuration change (see Integration Approach).

Technical risk. Still high and still concentrated in lifecycle, but the profile has shifted slightly:

• The claim of "no evidence of active maintainer" needs softening. 4.0 credits two outside contributors and lands real bug fixes, so there is community activity. But it is irregular, unreleased-cadence, and volunteer-driven — this is not a maintained dependency in the sense of a security-response commitment. The practical posture (fork and own) is unchanged.
• Zero-dependents / low-adoption blind spot persists. No downstream validation means no ecosystem pressure to keep it current and no CVE coverage. That remains the core mitigation driver for forking under an internal namespace.
• New risk introduced by 4.0: rendering HTML in a list view without visible sanitization guidance. If the team adopts the Symfony path, this must be gated on a sanitizer (HTML Purifier or Symfony's sanitizer component) before any user-facing deployment.
• The low opportunity score (14.69) is still consistent with a narrow, largely superseded capability.

Key questions for the team:

1. Is the target application actually Laravel, or is the stack Symfony/Legacy PHP and the ticket mislabeled? Unchanged, still the single answer that flips the recommendation. 4.0's Symfony-only upgrade path strengthens the case that this is not a Laravel package.
2. What channels are required — in-app only, or email/SMS/push/websocket? The bundle addresses in-app persistence only.
3. Do we need entity-agnostic attachment (notify users and teams and orders), or is user-only sufficient? If user-only, Laravel's built-in DatabaseNotification is strictly better.
4. New: Do we need HTML in notification bodies? If yes, where does sanitization live — in the bundle, in our templates, or in a pre-render step? 4.0's restored rendering makes this a blocking question, not a nice-to-have.
5. New: Are we on a 3.x install with a custom Notification entity? If so, 4.0 is a breaking upgrade requiring a config migration, not a drop-in patch.
6. What is the notification volume and retention policy? This drives the scaling work more than the library choice.

Integration Approach

Stack fit.

Recommended path (Laravel). Unchanged. Do not attempt a bridge; 4.0 makes the Symfony coupling more explicit rather than less. Treat the bundle as a specification for a schema:

• notifications table (id, type, payload JSON, created_at) — matches Laravel's DatabaseNotification shape.
• notification_notifiable pivot with notifiable_type, notifiable_id, seen_at — the one genuinely useful idea: multi-entity attachment with per-entity read state.
• Eloquent morphToMany on the notifiable side; a scoped unseen() query and a cached counter.
• Delivery via Laravel's Notification classes and channel manager.
• Sanitize payloads at render time. If the Laravel implementation mirrors 4.0's HTML-in-list behavior, use Blade's escaped output by default and an explicit, allowlist-based sanitizer where raw HTML is genuinely required.

Migration path — 3.x to 4.0 (Symfony). 4.0 introduces a breaking configuration change for custom-entity users. Sequence it explicitly:

1. Confirm whether a custom Notification entity is in use. If not, 4.0 is a low-risk patch-level upgrade.
2. If it is: remove the resolve_target_entities directive from the Doctrine configuration and add config/packages/mgilet_notification.yaml with mgilet_notification.notification_class: App\Entity\MyCustomNotification.
3. Verify NotificationManager::createNotification returns the custom class — this was previously broken, so any code branching on the returned type may now take a different path. Add a regression test that asserts the concrete class.
4. Verify list rendering: HTML output is restored, so existing Twig overrides and any downstream escaping assumptions must be re-checked against the new behavior.
5. Only then proceed to any framework-version modernization.

Compatibility checks before any commitment.

• PHP constraint in composer.json vs. your runtime.
• Doctrine ORM/DBAL major version compatibility; Doctrine 3 removed several APIs these bundles rely on.
• Custom-entity configuration path — confirm the 4.0 YAML config is picked up by the container before removing the Doctrine directive; a partial migration here silently falls back to the base entity.
• Symfony deprecation baseline: run phpstan at level 5+ against your target framework version. Budget 3–5 days for a Symfony 5 upgrade patch, more if Twig helpers are in play.

Sequencing.

1. Confirm the stack (half a day) — resolves Laravel vs. Symfony branch.
2. New: Triage 4.0 applicability (half a day) — custom entity in use? HTML rendering affected by our templates?
3. Spike (2–3 days): fork, run against target PHP/framework, produce a defect list.
4. Decide build-vs-port using a scored comparison against the native alternative.
5. Implement schema + domain layer, with a backfill script if migrating.
6. Cut over UI reads, keep the old path warm for one release cycle.

Operational Impact

Maintenance. Assume full ownership from day one. The 4.0 release slightly improves the picture — a real fix, external contributors, an explicit upgrade guide — but does not change the posture. There is no formal release cadence, no LTS commitment, and no security-response process to file against. Pin the fork to a specific commit, vendor it under an internal namespace, and keep it on the quarterly dependency-review list explicitly. Budget ~1 day/quarter for compatibility patches, plus a one-time cost for the 4.0 config migration if a custom entity is in use.

Support. Documentation remains README/thin, though 4.0's upgrade section is a genuine improvement — it documents the exact YAML incantation and the directive to remove. Onboarding cost is low in absolute terms because the API surface is small, but it requires Symfony/Doctrine fluency a Laravel-native team will not have. If ported to Laravel, ramp-up drops to near zero.

Scaling. Unchanged from the prior assessment; the notification table is the growth vector.

• Index (notifiable_type, notifiable_id, seen_at) — unseen-count queries are the hot path and will table-scan without it.
• Add a pruning job from the start; without retention this table becomes the largest in the schema within a year.
• Watch for N+1 on unseen counters; cache in Redis and invalidate on write.
• Payload is JSON/text — keep it small. 4.0 materially raises the cost of "rich" payloads because HTML bodies are now rendered: larger rows, more render cost, and a sanitization step on the read path if not pre-sanitized on write.

Failure modes.

Bottom line. 4.0 is a competent maintenance release that fixes a real custom-entity bug and restores HTML rendering, and it demonstrates that the project is not fully abandoned. It does not change the strategic conclusion: the bundle is functionally superseded on Laravel and architecturally stale on modern Symfony. Its realistic value is as a reference design for multi-entity notification attachment with per-entity read state. Anyone adopting 4.0 on Symfony inherits one breaking config migration and one new security obligation — sanitizing rendered HTML — both of which must be handled before release, not after.