Kudisms Notification Laravel Package

Technical Evaluation

Architecture fit. Unchanged, and the release does not touch it. This remains a thin Laravel notification channel — service provider plus a KudiSmsChannel — composing with mail/database/broadcast rather than replacing them. Nothing in 2.0.0 adds surface area; the diff is names, constraints, and dev tooling. That is the good news: the architectural judgement from the prior assessment holds without re-litigation.

Integration feasibility. The effort estimate changes from "low, contingent on three verifications" to "low, contingent on a platform prerequisite." 2.0.0 requires PHP ^8.3|^8.4 and Illuminate ^12.0|^13.0. If your application is on Laravel 11 or PHP 8.2 — plausible, given Laravel 11 is still inside its support window — this release is simply not installable, and upgrading the package means upgrading the framework first. That inverts the dependency direction: an SMS channel is now gating a platform upgrade. Two concrete traps worth naming. First, the PHP constraint is ^8.3|^8.4, which excludes PHP 8.5; if your platform roadmap targets 8.5, this package becomes the blocking constraint on a future upgrade, and you should raise it upstream now rather than discover it at cutover. Second, the vendor and namespace both changed (toneflix-code/kudisms-notification → toneflix/kudisms-notification, ToneflixCode\KudiSmsNotification → Toneflix\KudiSmsNotification), and the upgrade notes also tell you to update the published config — implying the config key or filename may have moved. Any config('…') reference, env var name, or queue/failure-handling override in application code must be re-verified, not just imports.

Technical risk. Mixed, and materially improved on one axis while a new axis opens.

Improved: the presence of Testbench ^10.11|^11.1 and Pest ^4, plus support for a Laravel major that did not exist at 1.1.1, is evidence of an active maintainer tracking the framework. The prior assessment's "assume frozen at the version you pin" posture should be softened — this is a maintained package, not an abandoned one. That is a real de-risking of the bus-factor and staleness concerns.

Newly opened — the vendor rename. A package rename is a supply-chain event, not a cosmetic one:

• Ecosystem signals reset to zero. Stars, download counts, and dependents do not transfer. The "zero dependents" finding must be re-derived for the new name, and the new name's history is empty by construction — you cannot distinguish a rename from a fresh, unreviewed package by looking at it. The migration instructions in the release notes are the only thing linking old to new; verify the Packagist record and the GitHub repo transfer independently.
• No stated replace/provide. The notes give a manual composer remove / composer require sequence but do not mention a replace directive for the old package name. If one is absent, any transitive dependency still requiring the old name will install both side by side, and you will have two notification channels registered under different namespaces. Confirm this before migrating.
• Typosquat risk. toneflix/kudisms-notification is a shorter, more generic name than before. Once the old name is deprecated, an unclaimed toneflix-code/* slot is a squatting target. Note the old vendor's disposition.
• Rename-only diffs hide regressions. "Everything is renamed" is exactly the kind of claim that lets a one-line behavioural change through review. Use git diff -M with rename detection against 1.1.1 and confirm the only functional deltas are the constraint bumps.

Key questions.

• Does 2.0.0 declare replace/provide for toneflix-code/kudisms-notification?
• Do committed tests actually exist, or is Pest only a declared dev dependency? Is there a CI matrix proving both Laravel 12 and 13?
• Is the 1.1.1 line receiving a final release with a deprecation notice, or is it silently orphaned?
• Did the published config filename or config key change, and are env var names stable?
• Is the diff against 1.1.1 genuinely rename-only once -M detection is applied?
• Why is PHP 8.5 excluded from the constraint — untested, or a known incompatibility?
• Does the vendor migration also change the GitHub org, issue tracker, or security disclosure channel?
• Still open from before: ShouldQueue correctness, non-2xx and timeout semantics, retry/backoff, per-message sender ID override, credential logging, delivery receipts.

Integration Approach

Stack fit. Two qualifying statements now sit in front of the previous one. The package fits a Laravel 12/13, PHP 8.3+ application serving Nigerian or West African users. It no longer fits a Laravel 11 estate, and a Laravel 11 estate should not upgrade its framework to obtain an SMS channel. The regional-gateway caveat stands unchanged: if multi-country delivery is on the roadmap, this is the wrong abstraction.

Migration path. 2.0.0 is a validation of the prior recommendation rather than a revision of it, and the two paths now diverge sharply:

1. Seam plus package (recommended if you have not yet integrated). The SmsSender interface plus adapter absorbs this release at the cost of a composer require and one binding line. The namespace churn becomes irrelevant — nothing in application code references Toneflix\… directly. This is precisely the scenario the seam was built for.
2. Vendored (recommended if you already adopted 1.1.1). If you copied the channel into app/, 2.0.0 delivers you nothing: the only changelog entries are the rename, constraints, and tooling. Do not re-integrate to chase a rename. Instead, diff 1.1.1 against 2.0.0 manually and cherry-pick anything behavioural, if it exists at all. Staying vendored forfeits the (now real) upstream maintenance, so record that as a deliberate trade, not an oversight.
3. Direct dependency on 1.1.1. The worst position: unmaintained and coupled. If you are here, migrate now — either to 2.0.0 behind a seam, or out to your own implementation.

Compatibility. Pin exactly, no caret range — unchanged advice, but now with sharper edges. Because the constraint jumps from (presumably) Laravel 10/11 to 12/13 in a single major, you should expect future releases to drop Laravel 12 on a similar cadence; a pinned version plus a Renovate PR you review manually is the correct posture. Add a CI job that runs your notification tests against both declared Laravel versions if you can afford the matrix, and at minimum against your target. Confirm the package does not constrain illuminate/support in a way that blocks Laravel 14, and log the PHP 8.5 exclusion as a tracked risk with an owner and a date.

Sequencing.

1. Platform check — confirm your runtime is PHP 8.3/8.4 and Laravel 12/13. If not, stop; 2.0.0 is out of scope and this becomes a platform-upgrade conversation, not a package-upgrade conversation.
2. Source audit — git diff -M 1.1.1 vs 2.0.0; confirm rename-only plus constraints, and read the test directory if it now exists.
3. Verify the Packagist/GitHub migration is legitimate and check for a replace directive.
4. composer remove then composer require toneflix/kudisms-notification:^2.0 (pin exact), re-publish config, and diff the published config against your existing copy before overwriting.
5. Update imports and any config() keys or env var names; grep the codebase for ToneflixCode to prove the swap is complete.
6. Run the existing Http::fake() test suite — success, 4xx, 5xx, timeout — and send one real SMS to a controlled number.
7. Staging canary, then production rollout starting with non-critical notifications before OTPs.

Operational Impact

Maintenance. The headline revision: this package is maintained, and the maintenance is active enough to track a new Laravel major and refresh its dev tooling. Budget for the opposite failure mode from the one previously described — not a frozen dependency, but a maintainer who will happily ship majors. Two majors in the package's visible history, with a vendor rename in the second, means you should plan for a breaking release roughly in step with Laravel majors. The mitigation is unchanged in shape and now clearly load-bearing: the seam or the vendor copy, plus an exact pin. Assign explicit internal ownership either way.

Support. Unchanged in substance — KudiSMS supports their API, not this wrapper — with one addition: the support surface moved. GitHub issues, security disclosure, and any historical discussion now live under a new org. Update the runbook's links, and note that issues filed against the old repository may go unread. Escalation remains: on-call reads the source, then contacts the gateway.

Scaling. No change. Throughput is gateway-bound, not package-bound. Confirm KudiSMS rate limits and per-message cost before building volume features; size queue workers for OTP bursts; add idempotency or dedupe at the application layer because retries against a non-idempotent gateway mean double billing. The only new scaling-adjacent note is the PHP ceiling — being unable to run 8.5 is a staffing-and-tooling constraint more than a throughput one, but it belongs on the same roadmap.

Failure modes. The previously listed quiet failures all still apply verbatim — swallowed errors, credential or sender-ID expiry, unqueued blocking calls, regulatory DND filtering, "sent ≠ delivered," credential leakage in logs. The release adds two migration-specific ones:

• Half-migrated namespace — old and new packages installed concurrently after the rename, with two channels registered and the old one silently preferred for some notifications. Detect by asserting a single registered channel in a boot test.
• Stale config key after re-publish — config:cache retaining an old key that no longer matches the package's lookup, producing an empty credential at send time rather than a startup error. Verify by clearing and rebuilding config as part of the upgrade, and by asserting a canary send immediately after deploy.
• Rename as cover for behavioural drift — the one genuinely dangerous case. The -M diff review in step 2 is the control; do not skip it because the changelog says "renamed."

Ramp-up. Developer ramp-up remains low — the mental model is the mail channel, the source is short, an hour end-to-end. The upgrade adds perhaps two hours of mechanical work (composer swap, import sweep, config diff, one canary). The real cost is unchanged and still non-obvious: KudiSMS's account model — sender ID approval, DND lists, credit top-ups — and the gateway's failure vocabulary. Half a day, budgeted against the gateway rather than the code. Add one item: whoever owns the upgrade should own the PHP 8.5 exclusion follow-up, or it will be rediscovered during a platform migration under time pressure.