Laravel Easy Sms Laravel Package

Getting Started

• Check the floor before anything else. v4.0.0 requires PHP 8.3+ and adds Laravel 13 support. Run php -v and composer show laravel/framework first; if either is below the floor, you are on the v3 line and should stay there until you can upgrade.
• Read composer.json before the README. The require block is the authoritative statement of which illuminate/* versions v4 actually accepts. "Adds Laravel 13 support" does not automatically mean Laravel 12 was dropped — verify whether the constraint is ^13.0 (hard cut) or ^12.0|^13.0 (additive). This single line determines whether the upgrade is a coordinated framework jump or a drop-in.
• Install and let Composer resolve the constraint:

  composer require <vendor>/<package>:^4.0 --with-all-dependencies
  

  Use --with-all-dependencies on the first install; a major bump frequently pulls transitive constraints that need re-resolution alongside the framework.
• Look for the upgrade guide. A major version with a PHP floor change almost always ships UPGRADE.md or a CHANGELOG.md entry listing removed methods, renamed config keys, and dropped support. Read that section before touching application code — it is the highest-signal document in the release.
• First use case: get one existing call site working end-to-end. Take the simplest place your app touches the package (usually a facade call, a helper, or an injected contract), run it against v4, and confirm the output matches what v3 produced. That validates autoloading, the service provider registration, and config resolution in one pass before you widen the blast radius.

Implementation Patterns

• Upgrade in a branch with a pinned framework. Bump laravel/framework and the package together in one commit so the lockfile reflects a coherent set. Upgrading the package first and the framework second is how you end up debugging a resolution error that masks the real breakage.
• Split the CI matrix by major. Run your existing PHP 8.2 / Laravel 11–12 leg against the package at ^3.0 and a new PHP 8.3 / Laravel 13 leg against ^4.0. Do not try to test both package majors in a single job — the dependency solver will fight you.
• Use a widen-then-narrow constraint during rollout. If the constraint permits it, temporarily allow ^3.0|^4.0 in a feature branch so you can run the suite against both, then narrow to ^4.0 once green. This is especially useful for catching behaviour drift that static analysis misses.
• Publish and diff config. If the package ships a config file, php artisan vendor:publish --tag=<package>-config into a scratch directory and diff against your existing published copy. Major versions routinely rename keys, and a stale published config silently wins over new defaults.
• Re-run publish for migrations and assets. Same reasoning for migration stubs and front-end assets: publish to a temp path, diff, then copy across only what changed. Never blanket-overwrite a published migration that has already run.
• Wrap third-party surface behind your own binding. Where the package exposes a contract, bind your own thin adapter in a service provider rather than calling the facade directly throughout the app. The next major then becomes a one-file change instead of a grep-and-replace.
• Exercise the queue and console paths explicitly. Package majors that bump the PHP floor often ride along with framework changes to job serialisation and command signatures. Run one queued job and one artisan command that touch the package as part of your upgrade checklist.
• Pin the major in composer.json, not the lockfile alone. "<vendor>/<package>": "^4.0" documents the intent; the lockfile documents the moment. Teams that rely only on the lockfile get surprised on the next composer update.

Gotchas and Tips

• PHP 8.3 breaks more than your app. Docker base images, CI runner images, and local tooling (PHPStan, Pint, older Xdebug builds) all need to move. Budget for the infrastructure change, not just the composer.json edit.
• "Adds Laravel 13 support" is not the same as "requires Laravel 13." Confirm the actual constraint. If older Laravel versions remain supported in v4, you can adopt the package major independently of the framework upgrade — a much cheaper first step.
• Resolution failures usually aren't the package's fault. When composer require fails after the bump, read the full conflict output; it names the specific package and version range blocking you. Nine times out of ten it is an unrelated dependency that also needs a major bump.
• Static analysis will move. A PHP 8.3 floor plus a Laravel major typically shifts Larastan/PHPStan baselines and surfaces newly-typed framework internals. Regenerate the baseline rather than suppressing errors individually, and review what got absorbed.
• Watch for silent deprecations, not just errors. PHP 8.3 tightens dynamic property creation and various implicit conversions. These emit deprecations rather than exceptions, so they pass CI and fail in production logs. Grep your logs after the upgrade rather than trusting a green suite.
• Check the service provider registration style. If v4 moved to Laravel 13's package discovery conventions, a manually registered provider in config/app.php or a bootstrap/providers.php entry can cause double registration or, worse, a stale class reference that fails only on certain code paths.
• Cached config and routes mask the upgrade. Run php artisan optimize:clear (or config:clear, route:clear, view:clear) before concluding anything is broken. A cached config from v3 pointing at a renamed key is the single most common false alarm after a major bump.
• Extension points are the thing to inventory. If you subclassed a package class, implemented an interface, or overrode a bound contract, check each one against the v4 source. These are the breakages Composer cannot detect and the ones that reach production.
• Keep a rollback path. Tag the last known-good v3 commit before merging the upgrade. Rolling back a major package bump plus a framework bump is far easier from a tagged commit than from a bisect.