Laravel Json Validation Testing Laravel Package

Getting Started

v2.2.0 is a compatibility release: the only documented change is Laravel 13 support. There are no new APIs, no deprecations, and no migration steps beyond the version constraint, so onboarding is unchanged from the rest of the 2.x line.

1. composer require <vendor>/<package>:"^2.2" — the caret on 2.2 is what actually gets you the widened illuminate/* constraints. An exact pin like 2.1.4 will silently keep you off Laravel 13.
2. Confirm auto-discovery picked up the service provider (php artisan about or check bootstrap/cache/packages.php). If your app has dont-discover entries, register the provider manually in bootstrap/providers.php.
3. php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>" and read the published config before changing anything — the defaults are usually the documented happy path.
4. First use case: run the package's simplest documented flow end-to-end (a single call, job dispatch, or HTTP round-trip depending on what it wraps) on a fresh Laravel 13 app before wiring it into your domain code. That isolates "does this even boot on 13" from "did I configure it wrong."

Where to look first, in order: the package's composer.json (constraints and PHP floor), the service provider (what gets bound and aliased), the config file (what's tunable vs. hardcoded), and CHANGELOG.md / UPGRADE.md for any 2.0-era breaking changes you may still be carrying.

Implementation Patterns

Pin the constraint in the app, not the lockfile. Declare "^2.2" in composer.json so the Laravel 13 support is explicit and reviewable. A composer update that bumps this transitively is a change nobody signed off on.

Wrap third-party calls in a thin adapter. A one-class seam (App\Support\<Thing>Gateway implementing your own interface, bound to the package class in a service provider) turns future major bumps — and test doubles — into single-file edits. This release is a good reminder: the thing that changed was a dependency constraint, not an API, and that's typical.

Keep config env-driven. Publish the config, then override only via config/<package>.php reading from env(). Never edit values inside vendor code or commit a config with credentials baked in.

Push anything slow onto the queue. If the package ships jobs or listeners, set an explicit queue connection per environment rather than inheriting the default; a package job landing on sync in production is a common surprise after upgrades.

Test against two Laravel versions. If you support 12 and 13 simultaneously, run a CI matrix with both. Compatibility releases are exactly where a method_exists/reflection shim quietly diverges between majors, and your own suite is the only thing that will catch it.

Use the package's fakes where offered. Most Laravel-native packages ship a ::fake() or an in-memory driver; preferring it over hitting real services keeps the suite fast and makes the upgrade verification meaningful.

Gotchas and Tips

• "Added Laravel 13 support" is additive, not a break. v2.2.0 should remain installable on 11/12. Still, run composer update --with-dependencies and then composer why-not <vendor>/<package> 2.2.0 if resolution fails — it names the exact package capping you.
• The PHP floor may have moved. Laravel 13 tracks a newer PHP minimum, and the package's require.php often moves with it. Check before assuming your CI image is fine; a green local build on a newer PHP than production is the classic false positive here.
• Read the actual diff, not the changelog line. composer diff <vendor>/<package> 2.1.x 2.2.0 (or the compare view on the repo) will show whether the constraint widening was accompanied by CI matrix changes, @deprecated annotations, or internal illuminate API swaps. The release note is one line; the commit range is the source of truth.
• Turn deprecations into failures in CI. phpunit.xml with convertDeprecationsToExceptions="true" (or the PHPUnit 11 equivalent) surfaces framework-level deprecations as red tests rather than log noise you'll discover a major later.
• Re-run config:cache after any config publish or upgrade. Stale cached config is the single most common "the package ignores my changes" cause in deployed Laravel apps.
• Transitive caps are the real blocker. Your app can require Laravel 13 and ^2.2 while some unrelated package still pins illuminate/support ^12. Resolve that first; it isn't this package's problem and no amount of constraint fiddling here will fix it.
• Extension points to prefer: container bindings and interfaces over subclassing the package's concrete classes, and package events over editing vendor code. Both survive minor releases untouched — which is precisely what v2.2.0 is.