Sms Sender Bundle Laravel Package

Product Decisions This Supports

• Informs the "SMS provider abstraction" build-vs-buy call — as a negative data point, not a positive one. The underlying idea (a SmsSender interface with swappable transport drivers so you can change providers without touching business logic) is a decision worth making. This package is evidence that the idea shipped in 2013–2014 and that the implementation did not survive. Treat it as prior art to cite in an ADR, not as a dependency to adopt.
• Supplier/vendor-risk calibration for the roadmap. 14 stars, 0 dependents, last release 2014-10-21, explicitly [DEPRECATED] in its own description. That is a complete abandonment signal. Use it as a reference case when setting your team's minimum bar for third-party adoption (maintenance recency, dependent count, explicit deprecation policy).
• Framework-fit gate for the platform decision. This is a Symfony2 bundle, not a Laravel package. It requires symfony/framework-bundle ~2.x, which directly conflicts with the Symfony 6/7 components Laravel 10/11/12 depends on. composer require will either hard-fail or attempt a framework-wide downgrade — a non-starter before any feature discussion happens.
• Scoping the notification/messaging epic. If SMS is on the roadmap, the decision this supports is "build a thin in-house SmsChannel + SmsProvider contract on top of Laravel's Notification system, with one concrete driver (Twilio/Vonage/SNS) behind it." This package contributes nothing to that build, but the interface shape it used is a reasonable starting sketch.
• Not a use case for: OTP delivery, transactional alerts, marketing sends, or any customer-facing surface — there is no viable integration path and no support channel.

When to Consider This Package

Effectively: never for a new or existing Laravel product. The criteria that would have to be true are all false here:

• You are on Laravel → immediate disqualifier. This is a Symfony2 bundle; there is no Laravel service provider, no facade, no config publishing, and the dependency graph is incompatible with modern Laravel.
• You are on Symfony2 / PHP 5.3–5.6 → still not recommended. Deprecated upstream, unmaintained for over a decade, unpatched. Any security review fails on sight.
• You need an SMS abstraction today → look at maintained Laravel-native options instead: laravel-notification-channels/* drivers (Twilio, Vonage, SNS, MessageBird), or a maintained framework-agnostic transport library if you need provider-agnosticism. Evaluate on: release cadence in the last 12 months, dependent count, PSR-18/PSR-17 compliance, and whether the provider SDK it wraps is itself maintained.
• You are doing historical research — a migration archaeology exercise, or evaluating why a previous SMS integration rotted — this repo is a legitimate reference artifact.

The only defensible reason to open the repository at all is to read its interface design for inspiration. Do not clone it into a composer.json.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. This is a dead dependency and there is no version of our stack where it works.

What it is: a 2014-era Symfony2 bundle that wrapped the SmsSender PHP library to give Symfony apps a provider-agnostic SMS layer. Its own maintainer marked it [DEPRECATED]. It has 14 GitHub stars, zero dependent packages, and its last tagged release was October 2014 — roughly a decade without a commit.

Why it fails for us, in one sentence each:

• Wrong framework. It is a Symfony2 bundle; we are on Laravel. Its required Symfony 2.x components conflict directly with the Symfony 6/7 components Laravel ships with — Composer will refuse or force a platform-wide downgrade.
• No maintenance. No security patches, no PHP 8 support, and no one to escalate to. Every CVE in that dependency tree becomes ours.
• No ecosystem. Zero dependents means zero field-tested usage and zero community answers when it breaks.

Recommendation. Fund a small, owned slice instead: a Laravel Notification channel plus a single SmsProvider contract with one production driver behind it (Twilio, Vonage, or SNS — pick by cost and regional coverage, not by library). Estimate: days, not weeks. That gives us provider portability on our own terms, on a maintained stack, with a named owner — which is exactly the outcome this bundle was trying to sell in 2014 and could not sustain.

Ask: approve the in-house abstraction over any third-party SMS middleware, and add "actively maintained + framework-matched" as a hard gate in our dependency review.