Laravel Client Laravel Package

Getting Started

This release (1.0.14) is a compatibility patch: it adds Laravel 13 to the support matrix and changes nothing else. There is no new API surface, so the getting-started path is unchanged — but the first thing to verify on any project is that the constraint actually resolved.

1. Confirm what you got. Run composer show <vendor>/<package> and check the installed version is 1.0.14 or later. If you are on Laravel 13 and Composer pulled an older tag, your root composer.json is pinning it — loosen the constraint to ^1.0 rather than a hard 1.0.13.
2. Check the platform floor. Laravel 13 requires PHP 8.3+; the package inherits that. If CI runs 8.2, the install will fail on the platform check, not on the package itself.
3. Read the service provider first. Laravel packages almost always register bindings, config, and optionally migrations in a single provider. That file is the map of everything the package can do — read it before the README, since the README often lags a patch release.
4. Publish and diff config. php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider" --tag=config (adjust the tag). Publish into a scratch branch, read the defaults, then decide what to actually commit. Don't publish blindly on a production branch.
5. First use case. Wire the package into one route or one artisan command and hit it manually before touching anything app-wide. A single integration point gives you a clean signal that config, container bindings, and autodiscovery all work.

Because this is a patch release, there is no migration guide to follow. Treat 1.0.14 as a drop-in and spend your onboarding time on the existing docs.

Implementation Patterns

Resolve from the container, never new. Laravel packages bind their core objects as singletons so config is applied once. Injecting the interface (or resolving via app()) keeps you on the configured instance; instantiating directly bypasses every config value and produces bugs that only appear in production.

Keep configuration in config/. Publish the package config and override only the keys you need. The most common day-two problem is an app that reads package settings from env() calls scattered through service classes — that breaks the moment someone runs php artisan config:cache.

Use it inside queued jobs deliberately. If the package holds request-scoped or connection-scoped state (HTTP clients, DB connections, tenant context), a long-running queue worker will reuse a stale instance. Resolve fresh inside handle() and let the container manage the lifecycle.

Wrap it in one thin adapter. Even for a package you like, put a small app-level class between your domain code and the package API. Patch releases like this one are safe, but the adapter is what makes the eventual major upgrade a one-file change instead of a grep across the codebase.

Test against the fake or the contract. If the package ships a fake (Package::fake()) or binds an interface, swap it in feature tests. If it only offers a concrete class, bind a stub for the interface in TestCase::setUp() and keep integration tests — the ones that hit the real thing — in a separate, slower suite.

Verify the support matrix in CI, not locally. A patch that only widens a constraint is exactly the kind of change that passes on your machine and fails in a matrix job. Add Laravel 13 to the CI matrix explicitly; don't infer compatibility from a green build on 12.

Upgrade order for a multi-app fleet. Bump the package in one low-risk app first, run the suite, then propagate. On Laravel 13 projects you can usually do composer update <vendor>/<package> --with-dependencies and review a diff that should be empty apart from composer.lock.

Gotchas and Tips

• A patch bump can still be a resolution trap. "Add Laravel 13 support" changes composer.json constraints. If your lock file pins 1.0.13, composer update is required — composer install will happily keep you on the old version while your composer.json claims ^13.0 support.
• composer why-not <vendor>/<package> 1.0.14 is the fastest way to see which transitive dependency is blocking the upgrade. It names the conflicting package and its constraint directly.
• Check illuminate/* constraints, not just laravel/framework. Some packages declare individual component constraints; a mismatch on illuminate/support breaks the install even when the framework line looks correct.
• Laravel 13 drops older PHP. If the package's own require still lists php: ^8.1, that's the package being permissive, not a guarantee it works — the framework floor governs.
• Autodiscovery caches. After upgrading, php artisan package:discover and php artisan config:clear. A stale bootstrap/cache/packages.php will keep the old provider registered and produce confusing "class not found" errors after a version change.
• Config caching hides env reads. If behaviour changes only after php artisan config:cache in deploy, the package (or your override) is reading env() at runtime. Move it into a config file.
• Deprecation noise is the real signal. Run the suite with deprecations surfaced (phpunit with --display-deprecations, or check storage/logs after a smoke test). Laravel 13 support now often means the package has already removed Laravel 12-era APIs — those are your future breakages.
• Don't fork for a constraint. If you need Laravel 13 and the maintainer hasn't tagged it, prefer a composer.json replace/alias only as a short-lived stopgap, and open an issue. This release is evidence the maintainer is responsive; use that channel.
• Watch the version number, not the changelog line. A one-line note at 1.0.14 signals the maintainer treats constraint widening as a patch. That's healthy, but it means the next 1.1.0 is where you should read carefully.
• Extension points are unaffected here. Whatever hooks existed in 1.0.13 — custom resolvers, driver registration, macros — still exist. This release adds no new ones, so resist the urge to re-read the source looking for new features; there aren't any.