Laravel Open Graphy Laravel Package

Getting Started

Version 1.3.0 is a compatibility release: it adds Laravel 13 support. Nothing in the public API changes, so treat this as a "bump and verify" upgrade rather than a feature to learn. Start by confirming the constraint actually resolved:

composer require your-vendor/this-package:^1.3
composer show your-vendor/this-package   # confirm the installed version

Then check composer.json in the package (or composer why-not) to confirm the framework constraint now includes ^13.0 and that the illuminate/* requirements moved in lockstep. If you are still on Laravel 12, ^1.3 should install fine — the release widens support rather than dropping it.

Where to look first:

1. The package's composer.json — the framework/PHP constraints are the only real behaviour change in this release.
2. config/ inside the package — publish it with php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" and diff against your existing published copy before committing.
3. The service provider's register()/boot() — confirm nothing that used to be conditional on the framework version has been reordered.

First use case: after upgrading, run your existing test suite against Laravel 13 in a branch before touching application code. If the suite is green, you are done. If not, the failures will almost always be framework-side (deprecations in the host app), not package-side.

Implementation Patterns

Pin the major, not the patch. Require ^1.3 in composer.json and let the lockfile do the rest. Avoid 1.3.* if you want to pick up future Laravel 13 fixes without a manual bump.

Upgrade in isolation. Do the Laravel 13 bump and the package bump in a single commit with no other changes. When something breaks you want exactly one variable in play. A clean pattern:

git switch -c upgrade/laravel-13
composer require laravel/framework:^13.0 --update-with-dependencies
composer require your-vendor/this-package:^1.3 --update-with-dependencies
php artisan test

Resolve through the container, not new. Since 1.3.0 is a support-widening release, the constructor signatures you already depend on are stable — keep injecting the package's classes via the container so future major versions can swap bindings without touching call sites.

Config-first integration. Read every tunable from the published config and reference it through config('this-package.*') rather than hardcoding. This keeps you able to switch drivers/connections per environment (queue workers vs. web, testing vs. production) without code changes.

Test with the package's fakes where offered. If the package ships a fake or an in-memory driver, bind it in setUp() for feature tests and keep one or two integration tests hitting the real implementation. This is the cheapest way to prove the Laravel 13 upgrade didn't silently change behaviour.

Matrix your CI. Add a Laravel 13 job alongside your existing 12 job for one release cycle. It costs a few minutes per build and catches constraint drift early.

Keep the framework and package bumps coupled in review. Because the package's only 1.3.0 change is the support matrix, a reviewer can verify the whole upgrade by reading two composer.json files plus a green CI run.

Gotchas and Tips

Constraint deadlock is the most likely failure. If another dependency still caps illuminate/support at ^12.0, composer require will resolve to the old package version and silently leave you on 1.2.x. Always verify the installed version with composer show rather than assuming the require succeeded as intended.

Clear the config cache after upgrading. php artisan config:cache during deploy will bake in whatever config file exists at build time; if you published a new config stub in 1.3.0 and didn't re-publish, you may be running with missing keys. Run php artisan config:clear locally and diff the published config against the package's stub.

Watch package auto-discovery. If your composer.json has "extra": { "laravel": { "dont-discover": [...] } }, the new version's provider registration won't apply automatically — check bootstrap/providers.php (Laravel 11+) as well as config/app.php on older layouts.

Don't assume "support" means "tested everywhere." A widened constraint is usually backed by a CI matrix, but confirm the package's CI actually runs Laravel 13. If the test matrix isn't visible, run the suite yourself; that is the assessment that matters.

Framework deprecations will look like package bugs. After the upgrade, exceptions pointing at package internals are frequently triggered by host-app changes (config defaults, container resolution order, removed helpers). Bisect by reverting only the framework version first.

Extension points are the safe place to intervene. If you need to adapt behaviour for Laravel 13 without forking, prefer the package's published config, container bindings (rebind an interface in a service provider), and any documented macros/extension hooks. Patching vendor/ guarantees you'll repeat the work on 1.3.1.

Log the resolved version at boot in non-production. A one-line Log::debug() of the package version in a service provider has saved more debugging time than any other habit when multiple environments drift.

Plan the next hop now. Since 1.3.0 is purely additive, the risk surface for 1.4.x/2.x is unknown. Pin ^1.3, read the changelog before each minor, and keep the upgrade commit pattern above — it stays cheap only if you keep it small.