Laravel Request Query Laravel Package

Getting Started

This release is a compatibility bump — v0.1.7 adds Laravel 13 support — so the first task is confirming the version constraint actually resolves before you plan any adoption work.

composer require <vendor>/<package>:"^0.1.7" --with-all-dependencies
composer why-not <vendor>/<package> 0.1.7   # if the resolve fails

Then:

1. Check the constraint, not just the tag. Confirm composer.json declares illuminate/support: ^11.0|^12.0|^13.0 (or similar) rather than a bare ^12.0. A release note saying "support laravel 13" is only meaningful if the constraint was widened.
2. Confirm the service provider registered. Laravel 13 still uses package discovery; run php artisan about and look under the providers/cache sections, or php artisan vendor:publish --provider="..." and check the list is non-empty.
3. Publish and diff config. php artisan vendor:publish --tag=<package>-config then diff the published file against whatever you already have committed — v0.1.x releases frequently add config keys without calling them out.
4. First use case: a throwaway feature test that boots the provider and exercises the single most basic code path (one facade call, one injected dependency). Do not start with the integration you actually care about — you want to isolate "does the package boot on L13" from "does my usage of it still work".

Because this is pre-1.0, treat the upgrade as "re-validate", not "trust the changelog". 0.1.6 → 0.1.7 can legally contain breaking changes under semver.

Implementation Patterns

Pin exactly in composer.json while pre-1.0. "<vendor>/<package>": "0.1.7" rather than ^0.1. With a package publishing patch releases on a 0.1.x line, ^0.1 lets a 0.1.8 in that silently changes behaviour. Bump deliberately, in its own PR.

Isolate the package behind your own boundary. Even for a small utility, wrap it:

// app/Services/Thumbnailer.php
final class Thumbnailer
{
    public function __construct(private \Vendor\Package\Client $client) {}

    public function make(string $path): string
    {
        return $this->client->generate($path);
    }
}

Resolve via the container and bind an interface in a service provider. When the package ships a 0.2 with a changed constructor or a renamed method, you edit one file instead of grepping 40 call sites — which is exactly the situation a Laravel 13 bump tends to create.

Prefer constructor injection over facades for anything touching queues, jobs, or console commands. Facades resolve from the container at call time; injected instances are resolved at construction and serialise predictably. If you must serialise a job that holds a package object, implement __serialize/__unserialize or hold an ID and re-resolve in handle().

Testing. Use orchestra/testbench for the package's own expectations, and in application tests lean on $this->instance() / $this->swap() to bind a fake into the container rather than mocking the facade:

$this->instance(Client::class, new FakeClient());

If the package exposes a ::fake() helper, prefer it — it usually hooks the container binding correctly and survives facade caching.

Multi-app / multi-version reality. If you maintain apps on both Laravel 12 and 13, keep CI matrixed on both against the same lockfile-per-version. The 0.1.7 constraint change means a single composer.json may now resolve differently on each app; don't assume a green build on one implies the other.

Config caching in deploy pipelines. Any config you publish must be part of the php artisan config:cache step, and any env-driven values inside it read at boot. If the package reads env() at runtime rather than at config-load, it will return null in production after caching — audit src/ for raw env() calls.

Gotchas and Tips

• "Supports Laravel 13" ≠ "Laravel 13 only." Verify the constraint still allows 11/12 if you need it. Some maintainers bump to ^13.0 exclusively, which is a much bigger deal than the changelog implies.
• Laravel 13 removes code that 0.1.6 depended on. Deprecations accumulated through 11 and 12 (and PHP minor-version bumps) get deleted in a major. If 0.1.7 is only a constraint change with no source diff, test the actual code paths — a green composer update proves nothing.
• Transitive conflicts are the usual failure mode. Your app resolving L13 is not enough; every other package must too. composer why-not laravel/framework 13.* is the fastest way to find the blocker.
• PHP version floor. Confirm your runtime meets Laravel 13's minimum before debugging anything else; composer check-platform-reqs catches it.
• config:cache masks boot errors. A provider that throws in register() may appear fine until the cached config is regenerated. Always run php artisan optimize:clear then optimize after upgrading, and watch for a silently empty published config.
• Long-running workers (Octane, Horizon, queue). Facade roots and package singletons bound in register() persist across requests. If the package caches per-request state in a singleton, you get cross-request leakage that only appears under load. Check for Octane compatibility notes or a flush/forgetScopedInstances hook.
• Extension points to look for before forking: Macroable traits, extend() on any manager class, custom driver registration, and container bindings you can swap() in a service provider. Any of these lets you patch behaviour without a fork — check src/ for them early, because forking a 0.1.x package is a maintenance sink.
• Debugging order of operations: php artisan about (did it boot) → php artisan tinker with a direct container resolve (does DI work) → a one-line feature test (does the call path work) → your real integration. Skipping straight to the last step conflates three failure modes.
• Watch the issue tracker, not just the changelog. For a pre-1.0 package, 0.1.7 being tagged days after a Laravel 13 release usually means a 0.1.8 follows within a week with fixes for the things the first pass missed. If you're not blocked, waiting is legitimate.
• Re-validate this assessment at 0.2.0. The upgrade to 0.2 is where the API stabilises and where a proper migration guide becomes worth writing; right now the correct posture is "adopt behind a wrapper, pin tightly, expect churn."