Laravel Model Migrations Laravel Package

Getting Started

• Minimum viable setup. composer require <vendor>/<package>:^2.0.3 — 2.0.3 is the first patch that declares Laravel 13 support, so any Laravel 13 application must pin at least this version. On Laravel 11/12, ^2.0 remains fine and 2.0.3 is a drop-in replacement.
• Where to look first. The package's composer.json (require/require-dev constraints tell you the real supported Laravel/Testbench matrix), then the service provider's register()/boot() methods, then config/ if the package ships publishable config. Those three files define almost everything you'll touch day-to-day.
• First use case. The most likely reason you're reading this release note is an application upgrade to Laravel 13. Treat 2.0.3 as an enabler, not a feature: bump the dependency, run composer update <vendor>/<package> --with-all-dependencies, then php artisan about and your test suite to confirm the provider boots and nothing in the container resolution changed.
• Publish and cache. php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>" (or --tag=<package>-config) followed by php artisan config:clear before you start debugging anything. A stale cached config is the single most common false alarm after a version bump.

Implementation Patterns

Upgrade-in-place workflow (the primary 2.0.3 scenario).

1. Bump the constraint to ^2.0.3 in composer.json.
2. composer update <vendor>/<package> -W so transitive dependencies resolve against Laravel 13.
3. php artisan config:clear && php artisan route:clear && php artisan view:clear.
4. Run the full suite; if it's green, run the app's smoke path that touches the package.

Resolution and injection. Prefer constructor injection of the package's contract/manager class over the facade in application code — it keeps the dependency swappable and makes it trivially fakeable in tests. Use the facade only at framework edges (middleware, Blade, console commands) where DI isn't available.

Encapsulate the package behind your own boundary. Wrap the package in a thin application-level service (e.g. App\Support\<Thing>Service) that owns configuration reads and error handling. When a patch like 2.0.3 lands, or a future 3.0 breaks something, you change one file instead of grepping the codebase.

Testing pattern. Bind a fake or stub in the container inside your test's setUp()/beforeEach() rather than hitting the real implementation. If the package ships its own fake or *::fake() helper, use that — it's usually maintained in lockstep with the public API. For feature tests, assert on your wrapper's output, not the package's internals.

CI matrix. If you maintain an application across Laravel versions, add a matrix entry for the new major (laravel/framework: ^13.0 + orchestra/testbench matching major) and keep the previous one. 2.0.3 makes this possible without forking the package; without it you're stuck on the older framework for as long as the matrix entry lives.

Scheduled/queued work. Anything the package does inside queue jobs or console commands is where framework-major upgrades usually bite (serialization, container rebinding, event signatures). Cover those paths explicitly in the upgrade PR rather than relying on the HTTP test suite.

Gotchas and Tips

• This is a patch, not a feature release. "Add support for Laravel 13" means widened constraints and compatibility fixes only — no new public API. If you were hoping for behavioural changes, there aren't any; if you were dreading breaking changes, there aren't any either.
• Patch-level version numbers can hide constraint bumps. Adding a new framework major is semantically a minor change at minimum. Verify the actual constraint in composer.json rather than trusting ^2.0 to be permissive — some maintainers release framework support as 2.0.x for consumers' convenience while the underlying require is ^11.0|^12.0|^13.0.
• Transitive dependencies are the real blocker. Laravel 13 support in this package doesn't guarantee your other packages support it. Run composer why-not laravel/framework ^13.0 to find the actual holdouts; it's rarely the package you expected.
• Service provider auto-discovery. If the app uses dont-discover, remember the provider is registered manually in bootstrap/providers.php (Laravel 11+) — new majors occasionally rename or move the provider class, so check after upgrading.
• Config drift between versions. If the package ships new config keys with a major, your published config/<package>.php won't have them. Diff the package's config file against yours on every major Laravel upgrade even when the package version only moved a patch.
• Debugging boot failures. php artisan package:discover and php artisan about give a much clearer error than a stack trace from a web request. If the app 500s immediately after the bump, run those first.
• Extension points stay stable across patches. Bindings, macros, and published config are your integration surface. If you find yourself extending a concrete class or overriding a protected method, you're outside the supported surface and every future Laravel-major patch becomes a manual merge — refactor to a container binding or decorator instead.
• Pin exactly when you need certainty. ^2.0.3 for normal use; 2.0.3 in a lockfile you don't control (e.g. a library's dev environment) if you need reproducibility across the L13 transition.