Ux Notify Laravel Package

Product Decisions This Supports

• Real-time in-app notification UX (or not). This package is the server→browser delivery layer for toasts/banners/streamed notifications. It informs a "do we ship a notification center this quarter?" decision — but only the presentation/delivery slice, not the durable inbox, preferences, or multi-channel orchestration.
• Build vs. buy on real-time transport. The package is thin; the real commitment is operating a Mercure hub (or paying for a hosted one). The build-vs-buy decision is therefore "Mercure vs. Pusher/Ably/Echo/Reverb vs. polling," not "adopt this library or not."
• Framework-fit gating decision (the dominant one). This is Symfony UX Notify, not a Laravel package. For a Laravel codebase the correct analogue is Laravel Echo/Reverb + broadcast notifications. Adopting this would mean running two ecosystems for one feature; the PM decision is a no on framework grounds before any feature merits are weighed.
• Maintenance-risk read. v3.6.0 is maintenance plus compatibility widening: MercureBundle ^0.5/^0.6 and Mercure ^0.8 support (minor #4036, #4056), a conflict fix against symfony/asset-mapper ≥8.2 (#3919), and asset/tooling hygiene (#4086, #3907, #3904). Signal: actively maintained and tracking Symfony's release train — but also transitively constraint-sensitive and still integrating pre-1.0 Mercure components.
• Roadmap sequencing. Because the dependency surface is small but the infrastructure surface is not, this belongs in an infrastructure/enablement track, not a feature sprint.

When to Consider This Package

Adopt when:

• The application is Symfony (6.x/7.x) using Twig/Turbo/AssetMapper — Laravel/other PHP frameworks are a hard disqualifier for the code itself.
• You already run, or are prepared to run, a Mercure hub and can own its JWT auth, topic design, and per-user authorization.
• Your notification need is genuinely ephemeral and server-initiated (price ticks, job completion, "someone commented"), where a dropped event is acceptable.
• You want minimal custom JavaScript: the shipped assets + Twig component story is the value proposition.
• You can pin versions. The asset-mapper conflict fix in this release shows that transitive constraints bite; treat this as a lockfile-hygiene requirement, not a red flag.

Look elsewhere when:

• Laravel. Use Laravel's notification broadcasting + Echo/Reverb/Soketi, or a simple JS toast library plus polling. Do not introduce Symfony UX into a Laravel app.
• You need guaranteed delivery, read state, history, or user preferences — this is a presentation layer, not a notification system of record.
• You need email/push/SMS fan-out or templating/digest logic; that is an orchestration concern above this package.
• SSE fan-out at high concurrency is your profile and you cannot horizontally scale Mercure — evaluate a managed pub/sub instead.
• You cannot absorb pre-1.0 Mercure component churn (MercureBundle 0.5/0.6): API surface may still move.

Verdict on v3.6.0: additive and non-breaking — no migration work, no deprecations, no security content. Nothing here changes an adoption decision; it slightly improves the compatibility story for teams already on Symfony + Mercure.

How to Pitch It (Stakeholders)

For executives (one paragraph): "Symfony UX Notify is a small, well-maintained integration that lets a Symfony app push live notifications to the browser. The v3.6.0 release is routine upkeep — broader Mercure version support and a dependency-conflict fix — with no breaking changes. The important caveat: this is not a Laravel package, so it is out of scope for our Laravel services; the Laravel equivalent is Echo/Reverb. Where it does apply, the library is cheap but the real cost is standing up and operating a Mercure real-time hub, plus per-user authorization. Recommendation: no action from this release; revisit only if a Symfony service needs live notifications and we are willing to own that hub."

For engineering (the honest summary):

• Scope of change: MercureBundle ^0.5/^0.6 and Mercure ^0.8 support; conflict resolved against symfony/asset-mapper ≥8.2; tooling/asset-manifest housekeeping. Low code surface, no BC breaks.
• Real work is not the dependency: it is Mercure deployment, JWT/topic authorization, reconnection and degraded-mode UX, and deciding what happens when an event is missed.
• Constraint hygiene matters: the asset-mapper conflict is a reminder to pin and to test upgrades of the Symfony asset toolchain together.
• Framework alignment is the gating question; if the answer is "Laravel," the answer to this package is no.