Sms Bundle Laravel Package

Getting Started

Before writing a single line, confirm what you are actually installing. yamilovs/sms-bundle is a Symfony bundle, not a Laravel package. It ships no ServiceProvider, no facade, and no config/sms.php. If your app is Laravel, you are signing up to be the integration layer yourself.

Minimal path:

1. composer require yamilovs/sms-bundle — then immediately check composer why-not php 8.1 (the last tag is from Oct 2018, so PHP 8 support is unlikely and Symfony 5/6 compatibility is doubtful; expect to pin an old framework or fork).
2. If you are on Symfony: register Yamilovs\SmsBundle\SmsBundle in config/bundles.php, then publish the bundle config (sms.yaml) with your provider credentials.
3. If you are on Laravel: skip the bundle wiring. Pull the provider classes out of vendor/yamilovs/sms-bundle/ and treat them as standalone library code behind your own SmsService. Register credentials in config/services.php and bind the client in a small SmsServiceProvider.
4. First use case: a single transactional send through one provider — password reset or OTP. Read the Providers/ directory first; that is the real surface area of this package, and it tells you instantly whether your gateway is supported.

Do not start by trying to make the bundle's DI extension load inside Laravel. It won't, and the time is better spent wrapping one provider directly.

Implementation Patterns

Provider-per-environment. The bundle's model is "one manager, many providers, pick one at runtime." In Laravel, mirror this with a config key:

// config/services.php
'sms' => [
    'default' => env('SMS_PROVIDER', 'twilio'),
    'providers' => [
        'twilio' => ['sid' => env('TWILIO_SID'), 'token' => env('TWILIO_TOKEN'), 'from' => env('TWILIO_FROM')],
        'nexmo'  => ['key' => env(' NEXMO_KEY'), 'secret' => env('NEXMO_SECRET')],
    ],
],

Then resolve the concrete provider class in a container binding, keyed by sms.default.

Service wrapper over the vendor class. The cleanest pattern is a thin SmsSender contract with send(string $to, string $message): bool, plus one adapter per bundle provider. This insulates you from the package going unmaintained (it already is) and lets you swap to laravel-notification-channels/twilio later without touching call sites.

Route sends through Notifications, not raw calls. If you stay in Laravel, prefer Notification + a custom channel that calls your SmsSender. You keep queueing, retries, and testing for free, and the bundle becomes an implementation detail.

Mock in dev. Configure a NullSender/LogSender for local and testing. The bundle does not ship a fake; write one. Assertions in feature tests should hit a recorded outbox, not a real gateway.

Log every request/response. The bundle does not give you delivery reports. Wrap calls with a small DB table or log entry capturing to, provider, message id, status, and error — you will need this the first time a customer says "I never got the code."

Gotchas and Tips

• It is not a Laravel package. No facade, no auto-discovery, no php artisan vendor:publish. Any "install" beyond composer require is your own code. Budget for that.
• 2018 release, 4 stars, 0 dependents. Treat it as a fork candidate. Before adopting, open composer.json in vendor/ and verify the PHP and Symfony constraints actually resolve against your stack. If they don't, fork, loosen the constraints, and run the test suite — do not use --ignore-platform-reqs in production.
• Provider drift is the real risk. SMS gateways change APIs (Twilio's Messages API versions, Vonage rebrand from Nexmo, SmsAero auth). A 2018 provider client will silently break on endpoints that were retired. Check the concrete provider class's HTTP calls against current docs before trusting it.
• No built-in retries, rate limiting, or idempotency. Add them yourself — a queue job with $tries = 3, backoff, and a dedupe key per message.
• Credentials in YAML. If you import the bundle on Symfony, remember sms.yaml ends up in git. Use env vars, and check the DI extension's parameter names by reading DependencyInjection/Configuration.php — that file is the authoritative list of options, not the README.
• Extension point for new gateways. Implement the bundle's provider interface (usually ProviderInterface with send(...)) rather than forking to add one gateway. Register it in your container and you keep upstream compatibility if it ever ships a release.
• Debugging. Start at the HTTP client: dump the constructed request URL and body for the failed send before blaming your config. Most failures here are auth header format or a from number that is not provisioned on the account.
• Verdict for day-to-day use: if you are on Laravel, use the gateway's own SDK or a maintained notification channel. Reach for this bundle only if you are already on Symfony and are pinned to an era where it works — otherwise it is a 2018 reference implementation, not a dependency.