Getting Started

Install inside a SeAT/Laravel application with composer require eveseat/notifications; the service provider is auto-discovered. Run php artisan migrate and clear caches (php artisan optimize:clear).
Look first at src/Notifications, the package service provider, and any published config/views. Review existing notification classes before writing your own—they are the best reference for channel payloads and registration.
First use case: notify a user or group when an in-game event occurs (structure attack, moon extraction, fleet ping). Create a notification class, register it so it appears in the user’s notification settings, then dispatch it from an event listener or queued job.

Implementation Patterns

Define notifications as classes that extend the package’s base notification or follow its expected contract. Implement via() plus channel methods such as toDatabase(), toMail(), and the Discord/Slack methods used by the package.
Register notification types with the package so users can opt in/out per channel. Treat user notification preferences as authoritative—do not assume Discord or mail is enabled.
Dispatch through Laravel’s notifier ($user->notify(new MyNotification($payload))) or the package’s group/role helpers when targeting many recipients.
Use ShouldQueue on notification classes and dispatch from listeners/jobs rather than controllers. This keeps web requests fast and lets slow webhook deliveries retry.
For plugin integration, map SeAT events to notification classes in listeners, keep payloads small and serializable, and pass IDs rather than Eloquent models into queued notifications.
Use Notification::fake() in tests and assert channel selection and payload shape. For local development, use log/database channels before enabling real Discord/Slack webhooks.

This is a SeAT package, not a generic standalone Laravel notification library. It expects SeAT’s user model, permissions, and UI conventions; standalone Laravel use requires additional wiring.
The 5.0.17 release is a notification-focused patch (“Lots of notification updates”, PR #115). No migrations or breaking changes are stated, but review the PR diff before deploying—channel formatting, links, or payload structure may have changed.
User preferences can suppress a channel even when your via() returns it. Test with a real user configuration, not only a hard-coded channel list.
Queued notifications can fail silently if workers are not running. Monitor failed_jobs and application logs, and inspect the notifications table when database delivery is expected but missing.
After updating, run php artisan config:clear and php artisan queue:restart. Config and queue workers can retain stale package settings.
Debugging checklist: verify the notification type is registered, confirm the user has the channel enabled, check storage/logs/laravel.log, inspect failed_jobs, and use Notification::fake() to isolate dispatch from delivery.
Extension points: custom notification channels, published views/assets, and overriding notification classes. Keep customizations in your own namespace where possible to reduce upgrade friction.