- Is symfony/light-sms-notifier a Laravel package?
- No. It is a Symfony Notifier bridge that provides a LightSms transport factory and transport for sending SmsMessage objects through the LightSms HTTP API. It has no Laravel service provider, config file, facade, or native notification channel. In a Laravel app you must write the glue yourself if you choose to adopt symfony/notifier alongside Illuminate\Notifications.
- How do I install symfony/light-sms-notifier in a Laravel app?
- Install it with Composer using symfony/light-sms-notifier, along with symfony/notifier and an HTTP client such as symfony/http-client. Then bind a Symfony Notifier and Transport in a Laravel service provider, register LightSmsTransportFactory on the Transport, and construct the DSN from your config. Expect roughly a day for a first-send spike, with more work for production concerns.
- What DSN format does LightSms Notifier use?
- The DSN format is lightsms://LOGIN:TOKEN@default?from=PHONE, where LOGIN is your LightSms login, TOKEN is the token from your account, and PHONE is your LightSms sender phone number. Build the DSN at runtime from separate environment variables rather than hardcoding it. The DSN embeds credentials in one string, so avoid dumping it in config cache artifacts, exception traces, or HTTP client debug logs.
- Which Laravel and PHP versions work with symfony/light-sms-notifier?
- The bridge release lines track Symfony majors: the 8.1 line requires PHP 8.4 or newer, the 7.x line targets PHP 8.2 or newer, and 6.4 is the LTS line. Laravel pins its own symfony/* component versions per Laravel major, so a Laravel 11 or 12 app on PHP 8.2 to 8.3 may fail resolution or need an older bridge line. Pin the bridge to the Symfony component line already used by your Laravel version and treat that as a hard constraint in your spike.
- Can I use Laravel Notification::fake() to test LightSms Notifier?
- No. Notification::fake() only fakes Laravel's native notification channels, not Symfony Notifier transports. For this bridge you mock HttpClientInterface or use Symfony's test doubles and assert against the transport behavior and generated DSN. Also test your Laravel service provider wiring, credential handling, and failure paths separately.
- How do I send an SMS through LightSms in a Laravel app?
- You create a Symfony SmsMessage, pass it to a configured Symfony Notifier, and let the LightSmsTransport send it through the LightSms API. In Laravel this usually means wrapping the call in a queued job rather than relying on Laravel's notification channel system. The bridge does not provide a native Laravel notification channel out of the box.
- Is symfony/light-sms-notifier production ready for Laravel projects?
- It is a small, Symfony-maintained adapter, but production readiness in Laravel depends on what you build around it. Queueing, retries, failure handling, credential management, and observability are your responsibility. LightSms is a niche vendor with little community evidence for this bridge, so verify delivery receipts, error codes, and rate limits directly with the LightSms API.
- What are alternatives to symfony/light-sms-notifier for Laravel SMS?
- Alternatives include a custom Laravel notification channel that calls LightSms directly, a direct HTTP client integration, or Laravel-friendly packages for providers such as Twilio or Vonage. Other Symfony Notifier SMS bridges exist, but swapping providers means changing packages, DSNs, configuration, and tests. The real decision is your SMS vendor, not the bridge abstraction.
- How do I handle queueing and retries with LightSms Notifier in Laravel?
- The Symfony Notifier transport does not give you Laravel queue semantics automatically. Dispatch a Laravel queued job that invokes the Notifier, configure tries and backoff on that job, and catch transport exceptions so failures are retried or recorded deliberately. Add logging and metrics around the job and transport call, because the bridge itself does not provide Laravel-native observability.
- Is symfony/light-sms-notifier actively maintained?
- It is a subtree split of symfony/symfony, so releases are cut automatically with Symfony releases and the repository will not disappear even if the LightSms vendor relationship ends. Abandonment risk is low, but the package has essentially no community dependents and few stars, so production evidence outside Symfony's own tests is limited. Pin a version that matches your Symfony component line and monitor Symfony release notes for changes.