Laravel Sens Alimtalk Laravel Package

Product Decisions This Supports

• Security posture / compliance sign-off: The v8.0.0 bump to guzzlehttp/guzzle ^7.15.2 closes CVE-2026-69245 and CVE-2026-69246. Guzzle 6 has no patched release, so staying on v7 is now a hard requirement for any environment with a vulnerability-management or SOC2-style gate. This is the strongest single reason to schedule the upgrade.
• Platform roadmap: Supports Laravel 13 and PHPUnit 13, and CI is exercised on PHP 8.1–8.5. This makes the package viable for teams planning a Laravel 13 upgrade in the next 12 months rather than a dead-end dependency.
• Build vs. buy: The package covers message payload construction, request signing, and a notification channel. If we were to hand-roll this, signing and payload shaping are exactly the parts we'd get subtly wrong. The 17 new tests covering signing and payload building materially reduce the "we could build this in a sprint" argument.
• Runtime floor decision: Minimum PHP raised to 8.1. This is only a decision point if any service we'd deploy it into still runs PHP 7.4 or 8.0 — check before committing.
• Future-proofing signal: Removal of dynamic properties in linkMobile()/linkPc() (deprecated in PHP 8.2, removed in PHP 9) tells us the maintainer is tracking the PHP 9 horizon. That is a positive maintenance signal for a long-lived dependency.
• Use cases: transactional notifications to mobile and desktop clients where delivery is via a signed HTTP request — the mobile/desktop link variants map cleanly to per-surface deep-link or redirect payloads.

When to Consider This Package

Adopt when:

• We need a Laravel notification channel that handles request signing and payload shaping for us, and we don't want to own the signing implementation.
• The service is on PHP 8.1+ and Laravel 10/11/12, with Laravel 13 on the roadmap.
• Guzzle 7.15.2+ is acceptable in the dependency tree — most modern Laravel apps already satisfy this.
• We want a dependency with an actual executable test suite. Before v8.0.0 the suite had zero executable tests; that caveat is now resolved.

Look elsewhere or wait when:

• Any target service is still on PHP 7.4/8.0 or pinned to Guzzle 6. v8.0.0 is a hard break on both, and Guzzle 6 cannot be made safe.
• We need an SLA, vendor support contract, or a published deprecation/versioning policy. This is a community package; v8.0.0 is a major-version break delivered without an LTS branch.
• Our dependency policy forbids major-version upgrades within a release cycle — the PHP floor and Guzzle floor move together here, so scheduling matters.
• The notification surface we need isn't mobile/desktop link delivery; verify the channel actually models our use case rather than bending it.

Upgrade planning note: treat this as a planned maintenance item, not a drive-by composer update. Two simultaneous floors (PHP, Guzzle) plus a PHPUnit schema migration mean CI config and any pinned dev dependencies need review in the same change.

How to Pitch It (Stakeholders)

To executives: This release is primarily a security and maintenance release for a notification dependency. It patches two known Guzzle vulnerabilities (CVE-2026-69245, CVE-2026-69246) by requiring Guzzle 7.15.2+, and it removes our exposure to PHP 9's removal of dynamic properties. Cost is a scheduled upgrade, not new development. The main coordination item is that it requires PHP 8.1+ — we should confirm no target service is below that before committing to a date.

To engineering: v8.0.0 is a breaking major. Three things change: minimum PHP is now 8.1, Guzzle is pinned to ^7.15.2 (Guzzle 6 is dropped because no patched release exists for the two CVEs), and linkMobile()/linkPc() no longer create dynamic properties. CI now runs PHP 8.1–8.5 and phpunit.xml.dist is on the PHPUnit 10+ schema, so the --verbose flag is gone. Positively, the test suite went from zero executable tests to 17 covering payload building, request signing, and the channel — that is the first real safety net this package has had, and it's why the PHP 7 removal is defensible rather than reckless. Plan the upgrade as its own PR with CI changes included, not folded into a feature branch.