Notifications Laravel Package

Product Decisions This Supports

• Transactional & lifecycle messaging without schema changes. On-demand notifications (NotificationDispatcherInterface::route() / routes() returning AnonymousNotifiable) let you notify an arbitrary address or identifier — a prospect who filled a form, a vendor contact, an email captured in a support flow — with no persisted model and no database record. This unlocks lead-nurture, invite, and pre-registration flows that previously required either a throwaway table or a queue job per message.
• Multi-channel delivery as a first-class product capability. The routeNotificationFor<Channel>() convention plus routing-before-delivery means a single notification can be composed once and delivered over mail, Slack, database, or a custom channel, with per-channel routing resolved by convention. Product can spec "notify via the user's preferred channel" without per-channel plumbing in each feature.
• Roadmap: channel expansion is now cheap. Adding a channel is a class with a name plus a routeNotificationFor<Channel>() on notifiables. Treat "add channel X" as a small, schedulable increment rather than an architecture item.
• Roadmap: safe-by-default suppression semantics. A channel is skipped when the route for that channel is empty, which gives product a native definition of "user has no route for this channel → don't error, skip." Useful for opt-in channels and partially-populated contact records.
• Build vs buy. Buy. The package provides routing conventions, a dispatcher interface, database-channel persistence, and now a maintained test suite across two TYPO3 majors. Rebuilding this in-house means re-implementing notification routing, channel keying, and suppression rules — none of which are differentiating.
• Quality signal for release planning. v1.5.0 ships unit and functional suites across TYPO3 13.4 and 14 (SQLite, DDEV supported). That is a credible maintainability signal and lowers the risk of depending on it for customer-facing messaging.
• Use cases to prioritise: on-demand form/lead confirmations, invite and onboarding sequences, ops alerts to Slack alongside an audit record in the database channel, and tenant-scoped notifications where recipients are configuration rather than user rows.

When to Consider This Package

Adopt when all of the following hold:

• You are on TYPO3 13.4 or 14 with a supported PHP version. Note explicitly: this is a TYPO3 extension (agencelex/notifications), not a Laravel package — it deliberately mirrors Laravel's notification API (notifiables, via(), routeNotificationFor*, anonymous notifiables), so Laravel familiarity transfers, but a Laravel codebase should use Laravel's own notifications instead. Confirm this with engineering before anything else, because the naming invites the mistake.
• You need multiple delivery channels from one notification definition, or expect to add channels over time.
• You have notifiables that are not persisted models (form submissions, external contacts) and want first-class support rather than ad-hoc mailer calls.
• You can absorb a breaking minor release. v1.5.0 is breaking despite the minor version, so your upgrade process needs to treat semver loosely here.

Look elsewhere when:

• You need only a single channel (plain mail) — a thin mailer is less to maintain.
• You depend on Laravel's notification ecosystem, queue integration, or Notifiable trait semantics — use Laravel.
• You need vendor-supported SLAs or long-term support guarantees; this is a small-team extension.
• You have not yet migrated to TYPO3 13.4+ and cannot schedule that move.

Upgrade cost for v1.5.0 (budget this explicitly):

1. Every notifiable used with a custom channel must now implement routeNotificationFor<Channel>(); unrouted channels are silently skipped, which converts a hard failure into a missing message. Add a delivery assertion to your test suite before upgrading.
2. Channels without getName() are keyed by short class name (SlackChannel, not the FQCN) — update every via() return value that used a fully-qualified key.
3. Route method names are derived from the channel key in UpperCamelCase (my-channel → routeNotificationForMyChannel()); verify existing method names still resolve.
4. Custom NotificationDispatcherInterface implementations must add channel(), route() and routes().
5. routeNotificationFor('database') returning true instead of null is intentional so the database channel is never skipped — do not "fix" it back.
6. Mail trait: only getEmail() is required now; the getLastName()-without-getFirstName() fatal error is fixed.

Plan a short migration spike plus a regression pass over every notification path, and specifically test the silent-skip behaviour — that is the highest-risk change for a product because failures become invisible.

How to Pitch It (Stakeholders)

For executives. This is the messaging backbone for our TYPO3 platform: one notification definition, delivered over mail, Slack, in-app database records, or future channels. The headline from v1.5.0 is on-demand notifications — we can message a person who is not yet a user in our system, removing a persistent blocker on lead capture and invitation flows that previously required a database workaround. The release also adds a maintained test suite across two TYPO3 versions, which reduces the risk of depending on it for customer-facing communication. Cost is a contained upgrade: a breaking release, so a short migration with regression testing, estimated at a few days of engineering rather than a project.

For engineering. Treat this as a breaking upgrade, not a minor bump. The dispatch path now resolves routeNotificationFor($channel, $notification) before every delivery and skips channels with an empty route, so any notifiable missing a route method stops receiving messages without an error. Custom channel keys change from FQCN to short class name for channels lacking getName(), the dispatcher interface gains channel(), route() and routes(), and route method names are derived from channel keys in UpperCamelCase. The mail trait is loosened (only getEmail() required) and a getLastName()-without-getFirstName() fatal is fixed. Sequence it as: pin the test suite first, add routing methods, update via() keys, migrate custom dispatchers, then verify database-channel delivery explicitly since it is now never skipped.

Ask. Approve the upgrade as a small scoped migration with a mandatory regression pass over all notification paths, and confirm the platform is on TYPO3 13.4+ — if the team is on Laravel rather than TYPO3, stop and use native Laravel notifications instead.