Laravel Model Meta Laravel Package

Getting Started

• Install with composer require <vendor>/<package>:^2.0.5. This is the first release in the 2.x line that declares Laravel 13 support, so the patch constraint matters: ^2.0 will resolve fine, but pinning ^2.0.5 guarantees you don't get an older 2.0.x build whose illuminate/* constraints reject Laravel 13 during composer update.
• If you are still on Laravel 10–12, 2.0.5 is a drop-in patch — no reason to hold back, and taking it now keeps you on a single version across projects.
• Where to look first, in order: the package's composer.json (confirm the illuminate/support / laravel/framework range actually widened and the PHP floor matches what Laravel 13 requires), the README's upgrade/requirements table, then the registered service provider and any publishable config. Laravel 13 support landing in a patch release signals an additive compatibility change rather than a re-architecture, so the public API you already know should be intact.
• First use case: register the package in a scratch Laravel 13 app, publish its config (if it ships one), and exercise the happy path from php artisan tinker or a single feature test. That confirms auto-discovery, config merging, and container bindings all resolve before you touch production code.
• If you maintain several apps on mixed Laravel versions, verify 2.0.5 on your oldest supported framework version too — the widened constraint is the only thing that changed, but that is exactly the kind of change that can mask a runtime incompatibility.

Implementation Patterns

• Resolve from the container, don't instantiate. Bind the package's service through constructor injection (or its facade, if it provides one) so that test doubles and config overrides work without touching call sites.
• Config over code. Publish the config file and drive behaviour through config/<package>.php plus env vars. Keep app-specific overrides in the config file rather than subclassing package classes — that survives patch upgrades cleanly.
• Constrain by patch, upgrade by minor. Use ^2.0.5 in composer.json and let Renovate/Dependabot open PRs for 2.0.x patches automatically; treat 2.1.0 as a manual review because feature releases are where behaviour can drift.
• CI matrix. Once you're on 2.0.5, add Laravel 13 to the test matrix alongside your current version (laravel/framework:^12.0 and ^13.0) with the matching PHP versions. A two-entry matrix catches the next compatibility break before it reaches a release.
• Testing. Use the package's fake/mock hook if it exposes one, or bind a test double in the container inside setUp(). Prefer asserting on the package's observable side effects (queued jobs, HTTP calls, written records) over asserting on internals.
• Long-running processes. If the package caches config or resolves singletons, restart queue workers and Octane after upgrading — framework-level patches plus container caching are a common source of "worked in tinker, failed in the worker."

Gotchas and Tips

• Framework support in a patch release is a constraint change, not a feature. Don't expect new APIs in 2.0.5, and don't assume the package's internals were reworked for Laravel 13. If something breaks, suspect Laravel 13's own deprecations first, not the package.
• composer why-not is your fastest diagnostic when the update won't resolve: composer why-not <vendor>/<package> 2.0.5 tells you which other dependency is still pinning an older illuminate/* range.
• Transitive constraints. The package may now allow Laravel 13, but a sibling dependency (a dev tool, a testing helper, an HTTP client adapter) might not. Run the full suite on Laravel 13 before merging, not just composer update.
• Lock files across repos. Bump to 2.0.5 everywhere in the same window; mixed patch levels across apps make it hard to attribute a regression to the package versus the framework.
• Deprecations are noisy but load-bearing. Turn on deprecation logging in staging after the upgrade and read it — Laravel 13 deprecations surfacing inside package code are the early warning for the next major.
• Extension points to prefer: the service provider's container bindings, config publishing/merging, and any documented macros or event hooks. Reach for those before forking; forking means re-applying your patch on every 2.0.x.
• If 2.0.5 misbehaves on Laravel 13, downgrade path is simply reverting the lock file to the last 2.0.x that worked — there is no schema or config migration implied by a framework-support patch, so rollback is cheap.