Laravel Paynl Laravel Package

Getting Started

V1.1.2 is a compatibility release: it adds Laravel 13 support and nothing else. There are no API changes, no deprecations, and no migration steps — which means the assessment stays the same in substance, but the upgrade path is now open for teams moving to Laravel 13.

Start by confirming the version constraint you actually need. On Laravel 12 or below, any recent 1.x tag works; on Laravel 13 you must be on ^1.1.2 or later. Check your composer.json for a pinned constraint like "vendor/package": "^1.0" — that will resolve fine — but a lock-file pin (1.1.1) or an explicit composer require vendor/package:1.1.1 will hold you back. Run:

composer require vendor/package:^1.1.2
composer show vendor/package   # confirm the installed version

First use case, unchanged from earlier releases: publish the config, wire credentials, and make one read-only call in tinker before touching application code. If the package ships a facade or a container binding, resolving it from tinker is the fastest way to confirm auto-discovery worked and that Laravel 13's container changes haven't broken resolution:

php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
php artisan tinker
>>> app(\Vendor\Package\Client::class)

If that resolves without a BindingResolutionException, you're integrated. Only then move to the real workload.

Implementation Patterns

The day-to-day shape of this package doesn't change in V1.1.2, but the Laravel 13 baseline shifts a few things worth building into your patterns now.

Inject, don't resolve. Prefer constructor injection over app() calls. Laravel 13 continues the long trend of tightening container behaviour around contextual and attribute-based binding, and constructor injection is the pattern that survives framework upgrades with the least friction. In jobs, listeners, and controllers, take the package's client/manager as a typed constructor argument.

Isolate the package behind one seam. Wrap calls in a thin application-level service (e.g. App\Services\ThingService) rather than scattering the package's API across controllers. When the next major release lands — and one will — you change one file, not forty. This matters more than usual here because the only signal in this release is framework compatibility; the package's own API surface is untested against a future major.

Config over code. Anything the package exposes via config/package.php should live in your published config file and, for per-environment values, in .env. Never edit files in vendor/. If the package exposes a manager/driver pattern, register custom drivers from a service provider rather than subclassing internals.

Test against the matrix you deploy. If you maintain a package that depends on this one, or you're mid-migration, add Laravel 13 to your CI matrix before you flip your app over. A green suite on 12 tells you nothing about 13.

Queue and event work. If the package dispatches events or jobs, assert on them in tests (Event::fake(), Queue::fake()) rather than hitting the real service. This keeps your suite fast and insulates you from payload changes in patch releases.

Gotchas and Tips

• The lock file is the whole upgrade. composer update vendor/package alone is usually not enough on Laravel 13 — the package's constraint now permits illuminate/*:^13.0, but Composer still needs the rest of your dependency tree to allow it. Run composer why-not vendor/package 1.1.2 to see exactly which package is blocking the bump. It's almost always a transitive dependency, not this one.
• "Laravel 13 support" is not "Laravel 13 tested." A compatibility bump widens composer.json constraints. Treat it as permission to try, not a guarantee. Smoke-test the paths you actually use — auth flows, queued jobs, pagination, serialisation — before shipping to production.
• Watch for silent deprecation noise. Laravel 13 raises deprecation reporting in some contexts. If your logs suddenly fill with notices from a vendor path after upgrading, that's the framework talking, not your code. Pin error_reporting in dev if it becomes unreadable, but don't suppress in production.
• Config caching will hide a bad publish. After php artisan config:cache, changes to the published config file appear to do nothing. Always php artisan config:clear when debugging configuration behaviour, and remember that .env is not read at all once config is cached.
• Auto-discovery can be disabled. If the package's provider isn't in bootstrap/providers.php (Laravel 11+ layout) or config/app.php, and discovery is off via composer.json's extra.laravel.dont-discover, nothing will work and the error will be a confusing missing-binding message. Check php artisan about to see registered providers.
• Extension points beat forks. Before patching vendor/, look for a published config key, a driver registration hook, or a container binding you can extend(). If none exists, wrap rather than fork — a fork is a permanent merge conflict on every future patch release.
• Pin to a range, not a patch. ^1.1.2 is right; 1.1.2 is a trap that blocks security patches.
• Re-run the assessment when a 2.x appears. This release carries no features and no breaking changes, so the day-to-day story is flat. The interesting release will be the one that changes the API surface — that's when the integration seam described above earns its keep.