Notifications Laravel Package

Product Decisions This Supports

• Build vs. buy for EVE Online alerting. This package supplies the ingestion-and-dispatch layer for EVE ESI notifications inside the SeAT ecosystem (structure attacks, war declarations, sovereignty timers, moon extraction, corp/alliance events). Adopting it avoids building and maintaining ESI polling, notification parsing, and channel fan-out in-house.
• Roadmap sequencing for ops/automation features. If near-term roadmap items include "notify leadership when a structure is reinforced" or "push war-decl alerts to Discord," this package is the shortest path; treat it as a dependency to validate before committing those dates.
• Channel expansion decisions. Because the release is a broad "notification updates" pass, it's a reasonable moment to evaluate whether the supported delivery channels match your target channels (chat ops, webhooks, mail), rather than building custom transports.
• Scope boundary: platform vs. product. Decide explicitly that EVE notification plumbing is platform (consumed, not owned) and keep product engineering focused on the workflows and dashboards built on top.
• Do not conflate with Laravel's built-in notifications. This is a domain-specific package for EVE/SeAT data, not a replacement for laravel/framework notifications. Confirming that distinction early prevents a wrong-architecture decision.

When to Consider This Package

Consider it when:

• You are already running SeAT (or planning to) and your users, tokens, and character/corp data live there. The package assumes that data model and auth context; the value collapses without it.
• Your product needs EVE notification ingestion plus routing to human-facing channels, and you would otherwise write ESI polling, dedupe, and formatters yourself.
• You can accept community-maintained velocity: patch releases with terse changelogs, and upgrade testing as your responsibility.
• You want the notification taxonomy and formatting conventions handled for you rather than specified by your team.

Look elsewhere when:

• You are not in the EVE Online domain — this carries no value for general application notifications.
• You need a vendor SLA, security review artifacts, or a support contract; this is a volunteer-ecosystem package.
• You require a standalone service decoupled from SeAT's schema and release cadence.
• Your notification requirements are simple enough that Laravel's native notification system plus a small ESI client is less total cost than adopting an ecosystem dependency.

On 5.0.17 specifically: it is a patch-level release bundling "lots of notification updates" (PR #115) with no documented breaking changes, migrations, or deprecations. It is low-risk but also low-information — the changelog does not itemize behavior changes. Treat it as safe to adopt, not safe to adopt blind: pin the version, run your notification-routing paths in staging, and read the PR diff if notification payload shape or delivery behavior is load-bearing for you.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can get EVE Online operational alerting — structure attacks, war declarations, timers — into our chat and workflow tools without building the integration ourselves. The trade-off is a dependency on a niche, community-maintained package tied to the SeAT platform, so the realistic risk is maintenance and upgrade effort rather than licensing cost. The latest release (5.0.17) is a small, non-breaking update; no action or budget decision is required beyond keeping the dependency current.

For engineering: Patch release 5.0.17, semver-compatible, no migrations or deprecations called out. The changelog is an aggregate ("lots of notification updates") rather than itemized, so verify against the PR diff before rollout. Recommended posture: pin the exact version, exercise notification ingestion and delivery in staging, and confirm whether any handler changes affect payloads we consume downstream. Flag the bus-factor risk — this is a single-ecosystem package; keep our integration surface thin (consume events, don't fork internals) so we retain the option to replace it.