Smspilot Notifications Laravel Laravel Package

Getting Started

• Confirm your host app's Laravel version before anything else: php artisan --version. This release requires Laravel ^11.0 and adds support through 13.x. If you are still on Laravel 10, stay pinned to ^2.7 — Composer will refuse the upgrade otherwise.
• Install/upgrade with an explicit constraint so you control the rollout: composer require vendor/package:"^2.8" --with-all-dependencies
• Look first at the package's service provider and config/ directory in vendor/ — the provider is where bindings, publishable config, and publishable migrations are registered. Publish only what you intend to own: php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider"
• First use case: wire the package into a single route or console command behind a feature flag, exercise it against a staging database, and only then roll it across the app. This release is a compatibility bump, so the goal of your first integration is proving nothing you already rely on has shifted.

Implementation Patterns

• Version pinning as a policy, not an accident. Keep ^2.8 in composer.json and commit composer.lock. Since the floor moved to Laravel 11, add a CI matrix that runs the suite against Laravel 11, 12, and 13 rather than trusting a single-version green build.
• Resolve from the container, don't instantiate. Bind the package's entry class in a small app-level service provider and inject it. When a future release renames or restructures internals, you change one binding instead of every call site.
• Treat config as app-owned. Publish the config file once, then read values via config('package.key') and back them with env() entries. Never edit files under vendor/ — they vanish on the next composer update.
• Upgrade workflow for patch/minor bumps. Branch → composer update vendor/package --with-dependencies → run the full test suite → grep the log for deprecation notices → merge. For a release like this one, budget the effort for the dependency graph, not the package's public API.
• Parallel-run before cutover. If the package touches persistence or queued work, deploy to a staging environment with production-shaped data and run both the old and new versions against read-only traffic before flipping.
• Keep dev tooling in lockstep. This release refreshed dev dependencies, which often means new rules in static analysis and code-style tooling. Run your linters as part of the upgrade PR so formatting churn lands in the same commit as the bump, not scattered afterwards.

Gotchas and Tips

• The ^11.0 floor is the real breaking change. Nothing in the public API was deprecated, but the version constraint is a hard stop for Laravel 10 applications. If you maintain a package or an internal app that must support 10, split your constraint: "vendor/package": "^2.7 || ^2.8" and let Composer resolve per environment.
• Laravel 13 support is forward-looking. Verify whether 13 is stable in your context before assuming production readiness; test against it, but do not make it your only CI target.
• Docker image changes are contributor-facing only. PHP 8.5 and Composer 2.10 in the package's container say nothing about what your app must run. Laravel 11 supports PHP 8.2+, so test your own matrix rather than chasing 8.5.
• Composer 2.10 can shift resolution behaviour. Run composer update --dry-run first and read the diff. If you see unexpected transitive upgrades, pin the offenders temporarily rather than accepting a surprise major.
• Watch for silently dropped support. Release notes list additions and changes but rarely enumerate removals. After upgrading, diff vendor/vendor/package/ against your previous lock and confirm no public methods or config keys disappeared.
• Debugging entry points: php artisan about for environment facts, php artisan vendor:publish --list to see what the package actually exposes, and php artisan tinker to resolve the package's binding and inspect the concrete class and config it received.
• Extension points to prefer: config values, container bindings, and any published interface or event hooks the package advertises. Subclassing vendor classes is a last resort — it is the first thing to break on the next minor release.