Notifyx Laravel Package

Getting Started

This is a 1.0.0 with no published feature list, no migration notes, and a changelog that is only a commit link. Treat the src/ tree and the README's first code sample as the documentation. Everything below is written against the capabilities the package claims — multi-channel delivery, a fluent message builder, queue support, and a Livewire notification center — but confirm each one against the source before you design around it.

Order of operations:

1. Read the README's first code sample before anything else. It answers the one question that changes every later decision: is this a wrapper over Laravel's native Notification system (a Notification subclass with via(), or a channel registered via Notification::extend()), or is it a standalone sender with its own facade? Everything in Implementation Patterns branches on that answer.
2. Check composer.json before installing. The require block gives the supported Laravel/PHP range. extra.laravel.providers tells you whether the service provider auto-discovers. Note the exact FQCN — do not guess SaurabhPunia\NotifyX\NotifyXServiceProvider.
3. Install pinned: composer require saurabhpunia/notifyx:^1.0. Never float this one.
4. Publish and read the config. php artisan vendor:publish --provider="<FQCN from step 2>", or --tag=notifyx-config if tags exist. The config file is the real map of the package — channels, driver credentials, queue connection, and any Livewire polling interval live there. Read it end to end before writing code.
5. Grep the published config for env(. Five seconds now saves the config-cache debugging session described in Gotchas.
6. Smoke test in tinker. Send exactly one notification, on exactly one channel, to one notifiable. This isolates credentials and transport from application logic, which is where they are genuinely hard to separate — a misconfigured mailer and a malformed message both surface as the same class of exception.

Do not wire anything into a controller, observer, or Livewire component until step 6 succeeds.

Your first real use case should be the in-app bell, not email. The package is billed as a Notification Center for Laravel & Livewire, so the database-backed unread-count widget is the thing it most likely does better than rolling your own. Get that working and you have justified the dependency; if it turns out to be just a thin email wrapper, you have learned that cheaply.

Implementation Patterns

Decide native-vs-standalone on day one. If the package extends Laravel's notification system, use that path exclusively — you keep Notification::fake() in tests, the database channel, and an exit ramp. If it is a standalone sender, never inject its facade into controllers, jobs, or listeners. Bind it behind a one-method application interface (Notifier::send(Notifiable $to, Message $m)) in a service provider, and resolve the interface. Tests bind a fake in the container; swapping to native notifications later is a one-line binding change instead of a find-and-replace across the codebase.

Queue everything outbound. Look for ShouldQueue on the notification class, a queue key in the published config, or a connection setting. If none exist, wrap the send in your own queued job — a slow SMS provider turning a 200ms endpoint into a 10-second timeout is the single most common production regret with notification packages. The package claims built-in retry handling; verify what it actually retries (transport failure vs. provider-side rejection) before trusting it.

Separate message construction from channel selection. Build one message object, then decide channels as a distinct step. "What to say" stays testable with zero transport configured, and adding a channel becomes a config change. This matters especially if per-user channel preferences are on your roadmap — preference lookup should sit between the two steps, not inside the message.

Always persist a database row alongside the outbound channel. Email and SMS leave no audit trail and no way to answer "did the user actually get told?" If the package ships a database channel, send on ['database', 'mail']. If it doesn't, write your own record inside the same job that dispatches the send, so a retried job doesn't produce an orphan.

For the Livewire side, wrap the package component rather than using it raw. Publish its views if possible and put your own NotificationBell component in front of it. Two reasons: you control the polling interval (see Gotchas), and you can swap the underlying component without touching every layout that renders it.

Hook delivery status through events if they exist. Check the service provider for Event::listen calls or a shipped Events/ directory. Persist queued → sent → delivered → failed transitions there. Polling a provider's API for status is always worse — rate limits, cost, and lag.

Test with a fake, not a network call. If Notification::fake() works, use it. If the package is standalone, the interface binding from above lets you assert on the message object — subject, channel, recipient — without any HTTP layer involved.

Gotchas and Tips

Pin ^1.0 and read the changelog every minor bump, not every major. Semver guarantees are weakest at a first stable tag, and this project has zero stars and one release — the 1.0.0 number signals intent to stabilize, not a proven track record.

Record a baseline now. With no documented features or breaking changes, you cannot later distinguish "nothing changed" from "nobody wrote it down." Note the exact version in composer.lock, run one smoke test per enabled channel, and save the output. The next release will have something to diff against.

Config caching is the most likely production-only failure. If the config file calls env() at load time, php artisan config:cache bakes those values in permanently — changing .env on the server then silently does nothing until you re-cache. If you find env( calls, put real per-environment values in the config file itself and cache normally. And in local dev, php artisan config:clear after every config edit, or you will spend twenty minutes editing a file that isn't being read.

Auto-discovery fails silently. After composer dump-autoload, a provider namespace change means the package simply isn't registered — no error, just a class-not-found deep in your own code. php artisan package:discover and php artisan about are your two-second checks.

A Livewire notification center is a polling component — budget for it. An unread-count poll every few seconds, per open tab, per user, is real query load. Set the interval in config to something sane (30–60s), index the notifications table on (notifiable_type, notifiable_id, read_at), and consider a wire:poll only on the badge rather than the whole component.

Retries produce duplicates unless something deduplicates. A retried notification is a duplicate email or SMS. If the package exposes $tries/$backoff, set them; if not, wrap the send in your own job with those properties and make the send idempotent via a natural key.

Verify the HTTP payload, not the status code. Notification providers routinely return 200 with an error object in the body. Enable the package's debug or log channel in staging, send once, and read what actually went over the wire.

Find the three extension points before you need them: an interface in Contracts/ you can bind, a Manager-pattern class (which means custom drivers via extend()), and dispatched events. If everything is final with no interfaces, any customization means forking — worth knowing on day one rather than week six.

Keep the exit ramp real. This package may not survive its first year. The interface binding and native-Notification compatibility check are what make "remove the dependency" a day's work instead of a sprint. If you find yourself importing SaurabhPunia\NotifyX\* in more than two files, you've built the lock-in you were trying to avoid.