Backport Laravel Package

Product Decisions This Supports

• Build vs. buy for notification plumbing on a legacy stack. The recurring PM question is whether to fund a sprint of custom multi-channel notification code — a Notification base class, a channel manager, a Notifiable trait, queue integration, mail/database drivers — or adopt an existing abstraction. This package is the cheapest possible "buy": MIT-licensed, zero cost, and a drop-in replay of Laravel 5.3's notification API. It substitutes for roughly a sprint of hand-rolled plumbing, which is the strongest argument it has.

• Decoupling feature delivery from platform work. The real decision it informs is sequencing, not architecture. Adopting this lets a team ship a user-facing notification feature — password resets, invoice receipts, order-status pings, ops alerts to Slack — on Laravel 5.1/5.2 without first funding a framework upgrade. That lets you put the upgrade on its own track and judge it on its own merits, instead of holding a roadmap item hostage to a platform investment that may be several quarters out.

• Committing to a channel-agnostic notification contract. If the roadmap line is "notify users when X happens," this supports committing to a design where the notification is written once and delivered by mail now, with database/in-app, SMS, or chat added later without re-architecting. That de-risks phase-two channel expansion and keeps the contract stable as requirements grow.

• Making risk acceptance explicit rather than implicit. The dependency profile is itself a decision input: last release November 2016, 26 stars, zero dependents, PHP floor past end-of-life, no upstream triage path. Choosing this is choosing to own the code. For a bounded internal tool on a frozen stack that can be a legitimate call; for a customer-facing engagement surface with a multi-year horizon it is not. The PM's job is to make the trade-off visible instead of letting a team default into it.

• Prioritization of the upgrade itself. Because this is a bridge and not an architecture, adopting it forces a companion decision: when does the framework upgrade get funded? Pair adoption with a named owner and an explicit "remove backport, upgrade framework" ticket, or the stopgap quietly becomes permanent. The package's day-to-day value is buying velocity now; the discipline of writing 5.3-shaped code is what keeps that velocity from calcifying into a second legacy layer.

• Scoping of the notification MVP. The package's real supported surface is narrower than "notifications": mail, database, and broadcast, with custom channels as the escape hatch. That naturally shapes a phased scope — prove mail end-to-end first, add in-app via the database channel and the Notifiable trait's unreadNotifications()/markAsRead() methods, and treat SMS/chat as custom-channel work with its own estimate. It also flags likely gaps up front: markdown mail rendering and on-demand notifications (Notification::route(...), a 5.5 feature) should be validated before they appear in a commitment.

When to Consider This Package

Consider it when all of these hold:

• The application is genuinely pinned to Laravel 5.1 or 5.2, and the Illuminate\Notifications\* namespace is confirmed absent. Verify before anything else — on 5.3+ this dependency is dead weight.
• There is a near-term, user-visible notification requirement (transactional email, in-app inbox, ops alerts) and the framework upgrade is not funded, scheduled, or is explicitly several quarters away.
• The team accepts ownership: someone is named to vendor or fork the package on day one, pin the commit, commit tests, and carry a stewardship line in capacity planning. Budget hours to integrate and roughly a day to harden.
• The engineering team will write strictly against the Laravel 5.3 notification documentation — standard imports, via()/toMail()/toDatabase()/routeNotificationForMail(), Notification::send() — with no backport-specific APIs. This is the condition that makes the eventual exit a clean deletion.
• The surface is bounded and internal-facing, or the blast radius of a channel breaking is tolerable and can be mitigated with a channel allow-list and a custom-channel fallback.

Look elsewhere — or fund the upgrade instead — when any of these hold:

• You are on 5.3+. There is nothing to backport; use the framework.
• The notification surface is customer-facing with a multi-year horizon, and dependency age, EOL PHP floor, and the absence of an upstream security/triage path are unacceptable to your auditors or your support commitments.
• You need features that predate or postdate the 5.3 API boundary — notably on-demand notifications to non-model recipients, or modern provider SDK payloads for Slack/Nexmo/Vonage. Expect to build these as custom channels rather than get them for free.
• Composer resolution already fights your pinned illuminate/* constraints, or would require --ignore-platform-reqs or root composer.json constraint edits. That friction is a signal the stack is too entangled for a cheap shim.
• No one will own the fork, and no exit ticket will be filed. An unowned backport is a permanent commitment dressed up as a stopgap — a hand-rolled internal module with a supported owner is the better bet in that case.

How to Pitch It (Stakeholders)

For executives — the one-liner: This is a free, MIT-licensed library that lets us ship notification features on our current Laravel version now, instead of waiting on a framework upgrade. It costs us no license fee and replaces roughly a sprint of custom plumbing. The catch is that it is unmaintained, so we own it — which is why we're pairing it with a named owner and a scheduled exit.

• Roadmap impact: a committed notification feature (password resets, receipts, order-status, internal alerts) can ship this quarter rather than queuing behind a platform upgrade. The upgrade stays on its own track and gets judged on its own merits.
• Cost: zero license cost, roughly a sprint of engineering avoided, hours-to-days to integrate and harden, plus a small ongoing stewardship line.
• Risk, stated plainly: last release November 2016, 26 stars, zero dependents, no upstream fix path, EOL PHP floor. We are adopting a bridge, not an architecture. Mitigations: vendor/fork and pin commit on day one, register custom channels instead of patching vendor code, wrap dispatch behind an application-owned Notifier so the package is swappable, and keep every notification class written against the standard Laravel 5.3 namespace so removal is a deletion rather than a rewrite.
• The ask: one named owner, a hardening budget of about a day, and approval of an explicit exit ticket — "remove backport, upgrade framework" — filed at adoption, so this stays a stopgap by design.

For engineering — the framing: write every notification as if we are already on 5.3. Import from Illuminate\Notifications\*, use via()/toMail()/toDatabase(), use Notification::send() and $user->notify(), use routeNotificationForMail() for recipient resolution. Treat the Laravel 5.3 notification docs as the reference manual — there is no backport documentation site, and the vendor directory is the specification. Never reach for a shim-specific class; the moment someone does, that becomes permanent debt and the upgrade stops being clean.

Sequencing to commit to:

1. Confirm the 5.1/5.2 pin and verify the package's PSR-4 namespace mapping in composer.json before writing a line of code.
2. Register the provider and Notification facade alias manually (no auto-discovery on 5.1/5.2), publish the config and migration, inspect the notifications schema before running it.
3. Prove mail end-to-end to a real inbox or Mailtrap — that exercises the Notifiable trait, the channel manager, the MailMessage builder, and the riskiest bridge in the package.
4. Bring up the database channel through the trait's methods (unreadNotifications(), markAsRead()), not raw queries, so the query shape survives the upgrade.
5. One test per channel in production, no exceptions — Notification::fake()/assertSentTo() if they survived, otherwise a spy channel.
6. File the exit ticket the same day.