Laravel Sms Api Laravel Package

Getting Started

• Install the release that matches your framework. 4.1.0 is the line that adds Laravel 13 support, so on Laravel 13 pin ^4.1; on Laravel 10–12 the earlier 4.x releases remain valid and you don't need to move. Commit the lockfile either way.
• Look at the service provider first. Open vendor/<vendor>/<package>/src/*ServiceProvider.php before the README — it tells you what is bound into the container (singletons vs. scoped), what config is merged, which commands are registered, and which interfaces are the intended extension points.
• Publish and read the config. php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" (or --tag=<package>-config), then read the published file top to bottom. Laravel package config files are usually the most accurate documentation of defaults and driver options.
• Resolve from the container, not new. Your first real use case should be app(Client::class) / constructor injection in a controller, so the package's configured HTTP client, credentials, and test fakes actually apply. Hand-constructing the class bypasses all of it.
• Discover what it registers. php artisan about, php artisan list | grep <package>, and php artisan vendor:publish with no arguments will surface the commands, scheduled tasks, and publishable assets the package adds.

Implementation Patterns

• Constructor injection over facades. Inject the package's client/manager into controllers, jobs, and listeners. Facade calls inside queued jobs are harder to fake and can capture stale container state on long-running workers.
• Config file is the seam for environments. Put credentials in config/<package>.php reading from env(), and never call env() at runtime — with config:cache it returns null. Per-environment driver swaps (sandbox vs. live) belong in config/<package>.php, not in application code.
• Wrap it in a thin adapter. Define your own App\Services\<Thing> that depends on the package and exposes only the two or three methods your app needs. This gives you one place to update on the next major, and one thing to fake in tests.
• Push network-calling work to jobs. If the package talks to an external service, call it from a queued job with $tries, backoff(), and ShouldBeUnique (or a dedupe key) so retries and webhook re-delivery are idempotent. Use Bus::fake() and Http::fake() to assert behaviour without hitting the network.
• Prefer events/listeners over editing vendor code. Most packages dispatch events before/after the interesting operation — subscribe to them for audit logging, notifications, and cache invalidation.
• Scheduling and commands. Wrap scheduled package commands in withoutOverlapping() and onOneServer() if you run more than one node.
• Tests. Look for a shipped fake (Package::fake()) first; otherwise fake the underlying HTTP or queue transport and keep one small integration test against the real container bindings so config wiring is covered.
• Octane / long-running workers. Register the package's mutable clients as scoped rather than singleton in your own provider if you see state leaking between requests.

Gotchas and Tips

• PHP constraint, not the package, usually breaks the Laravel 13 upgrade. Laravel 13 raises the PHP floor, and Composer resolution failures after composer update are typically transitive (symfony/*, laravel/framework sub-packages) rather than this package. Run composer why-not laravel/framework 13 before touching the package constraint.
• Published config drifts. Upgrades rarely overwrite published config, so new options silently keep old defaults. Diff your config/<package>.php against vendor/<vendor>/<package>/config/ after every minor bump; use vendor:publish --force deliberately and re-apply your customisations.
• Provider not loading? Check bootstrap/cache/packages.php and run php artisan package:discover / composer dump-autoload. Stale discovery caches are the usual cause of "class not found" right after an upgrade.
• Debugging integration issues. Tap the package's HTTP client (or Http::globalRequestMiddleware) to log request/response pairs, and route its log channel somewhere separate — package debug logging is often noisy at debug level.
• Extension points to reach for before forking: bind your own implementation of the package's interface in a service provider ($this->app->bind(...)), use the manager's extend() for a custom driver, and use Macroable classes if the package exposes them. These survive minor upgrades; a fork does not.
• Test the upgrade on a branch against 4.1.0 specifically — it is the compatibility release, so it is the version your Laravel 13 CI matrix should pin. Keep a Laravel 12 job in the matrix until you have fully moved.