Laralerts Laravel Package

Getting Started

This release is a supersede notice, not a feature release. v6.3.1 changes nothing in the package's behaviour — it adds a pointer to Laragear/Alerts as the successor. Treat the package as being in maintenance/deprecation mode from this point.

Where to look first, in order:

1. The Laragear/Alerts repository — read its README and its own upgrade/migration notes before touching your composer.json. Everything below assumes you've confirmed the successor covers your use case.
2. Your composer.json and composer.lock — identify whether this package is a direct dependency or pulled in transitively, and which constraint you're on. This determines how much freedom you have.
3. Your own call sites — grep for the package's facade, helper functions, traits, and published config file. The breadth of that list is your migration estimate.

The first use case to validate: pick the single most trivial alert/notification path in your app (one that fires from a controller or an event listener), migrate it to the successor in a branch, and confirm parity — payload shape, channel/queue behaviour, and the resulting database rows. If that one path is clean, the rest is mechanical. If it isn't, you've learned that early and cheaply.

If you are evaluating this package for a new project: don't. Start on Laragear/Alerts.

Implementation Patterns

Isolate before you migrate. If your code calls the package directly from dozens of controllers and jobs, the migration is not a package swap — it's a refactor plus a package swap, and you'll conflate the two when something breaks. Wrap the existing calls behind a thin application-level service or interface (App\Alerts\Notifier or similar) with the old package as the only implementation. Ship that refactor on its own, with no behaviour change and green tests. Now the successor becomes a second implementation of the same interface, and the swap is a container binding.

Adapter-in-parallel, then cut over. Add the successor alongside the incumbent, route a small percentage of traffic (or a single non-critical alert type) through it, and compare outcomes. Alerting packages tend to differ in ways that only show up in production: whether queued delivery is the default, how they handle a missing recipient, whether they persist a record before or after dispatch.

Pin, don't float. Change ^6.3 to an explicit 6.3.1 (or a tight range). With no maintainer attention, a floating constraint buys you nothing but the risk of an unexpected transitive dependency resolution on a future composer update in CI.

Sequence the migration against your Laravel upgrade, not alongside it. The release notes cite "latest Laravel support" as a reason for the successor, which strongly implies this package will not track future Laravel majors. If you're currently on an older Laravel, migrate the package first on the version you're on, then upgrade Laravel — doing both at once makes failures unattributable.

Test the seams, not the package. Your test suite should assert on your own abstraction's contract (what was sent, to whom, with what data), not on the package's internal classes. That way the migration either passes your suite or it doesn't, and the package is never named in more than one place.

Gotchas and Tips

• v6.3.1 contains no code changes. There is no bug fix, no security patch, and no new feature to adopt. Upgrading from 6.3.0 to 6.3.1 buys you nothing; the only actionable information in the release is the supersede notice itself. Don't let a version bump create the impression that the package is actively maintained.
• "Superseded" is not "abandoned", but plan as if it is. There is no stated support window, no EOL date, and no commitment to security fixes. Assume the next Laravel major will break it and that no one will fix it. Set yourself a calendar reminder tied to your next Laravel upgrade.
• Watch for a replace or conflict declaration. If the successor declares replace on this package, installing it will remove the old one from your lock file — which is convenient, but it will silently delete the package while your old call sites still reference its classes. Expect a hard Class not found and sequence the code changes accordingly.
• Check for a published config file and migrations. Config files published to config/ and migration files already applied in production are not removed by a Composer operation. You'll need to decide whether to keep them, re-publish from the successor (which may use different key names), or leave orphaned tables behind. The orphaned-table decision is the one people forget until a later cleanup.
• Queued jobs are the sneaky breakage. If the package serialises its own job classes onto your queue, any in-flight jobs at deploy time will fail to unserialise once the class is gone. Drain the queue before deploying the removal, or keep the old package installed-but-unused through one full queue cycle.
• Don't read the absence of a deprecation warning as a licence to wait. Because the notice lives only in the release notes — not as a runtime trigger_error, not as a Composer abandoned flag — nothing in your tooling will remind you. Put the migration in the backlog with an owner, not just a note.
• If you must stay temporarily: keep the pin, add a test that asserts the package is still installed at the expected version, and document why you're staying and what unblocks the move. An undocumented "we'll get to it" is how packages end up in production five years past EOL.