Ux Notify Laravel Package

Product Decisions This Supports

• Notification UX layer, not a notification engine. ux-notify sits in the presentation layer — surfacing flash messages, async job completions, and system alerts as user-facing toasts/banners. It does not decide who gets notified, over which channel, or with what content. Treat it as a front-end rendering concern, not a replacement for Laravel's Notifiable/Notification or Symfony's Notifier.
• Build vs. buy: effectively "build lightly." With zero stars, zero dependents, and a composite score of 0, there is no adoption signal to justify a dependency. The realistic PM decision is to read it as a reference implementation for notification UX patterns and hand-roll 150–300 lines of Blade/Livewire + a small toast component, rather than adopt an unversioned, single-org package.
• Framework mismatch kills the Laravel case. The package is explicitly scoped to Krystal Symfony projects. In a Laravel codebase you would be adopting a Symfony UX convention (Symfony UX Notify / Turbo Streams semantics) and re-implementing the adapter yourself. That is a hidden cost most roadmaps won't absorb without a spike.
• Useful as a scoping input for a "Notifications v1" epic. Reviewing this package clarifies the real requirements list: transient vs. persistent alerts, severity levels, dismissal behavior, stacking limits, accessibility (ARIA live regions), and how server-rendered flashes interleave with async events. That requirements list is more valuable to the roadmap than the code.
• Vendor-risk decision. Single-org provenance (Krystal), no visible release cadence, no dependents. If your product depends on this for user-visible feedback, you own the fork on day one.

When to Consider This Package

Consider it if:

• You are already inside the Krystal/Symfony ecosystem and this is a first-party internal convention you're expected to follow.
• You need a thin, opinionated toast layer on top of Symfony UX and want to avoid inventing naming/severity conventions.
• You are running a short spike to benchmark your notification UX against an existing implementation.

Look elsewhere if:

• You're on Laravel. Use Livewire/Inertia + a maintained front-end toast library, or native session()->flash() with a Blade partial.
• You need actual delivery guarantees — email, SMS, push, digesting, retries, user preferences. That's Notifier / Laravel Notifications / a vendor like Novu or Courier.
• You need auditable notification history, read/unread state, or inbox semantics — none of that is a UX-layer concern.
• Your procurement or security review requires evidence of maintenance: release history, issue throughput, CVE response. None is available here.
• You need a supported vendor relationship. This is not a commercial product with SLAs.

Adoption gate before any real commitment: confirm the package is installable against your PHP/framework versions, confirm licensing, and confirm a named internal owner who will maintain a fork.

How to Pitch It (Stakeholders)

Executive summary: this is a small, first-party notification-UI component out of Krystal's Symfony work — essentially the "toast and banner" layer of a product, not the notification platform. It has no external adoption (zero stars, zero dependents) and is scoped to Symfony, so it is not a drop-in for our Laravel applications.

Recommendation to leadership: do not adopt as a dependency. Treat it as a design reference and fund a short internal build — roughly a sprint — for an in-house notification component with accessibility, severity levels, and a documented contract with our existing notification backend. This avoids a single-vendor fork obligation on a user-visible surface while giving us the same capability.

To engineering: the useful artifact here is the pattern, not the package. Read it for the server-to-client contract for transient messages, then implement against our own conventions. Budget for an accessibility review (ARIA live regions, focus handling, dismiss affordances) — that's the part teams consistently under-scope.

Risk framing: adopting a zero-dependent, single-maintainer package on a user-facing surface creates an implicit fork commitment with no upstream leverage. Building internally costs marginally more up front and materially less over two years.