Laravel Slow Query Detector Laravel Package

Getting Started

v2.1.0 is a compatibility release: it adds Laravel 10 support and moves the CI matrix to PHP 8.2. There are no new features or deprecations to learn, so day-to-day usage is unchanged from v2.0 — but the version constraints are the thing to verify before you commit.

Start here:

1. Confirm the constraints. After composer require <vendor>/<package>:^2.1, open the installed composer.json and check illuminate/support, illuminate/contracts, and php. Laravel 10 support means ^10.0 is now allowed alongside 9.x; if you are still on Laravel 9, v2.1.0 should be a drop-in bump. If you are coming from 1.x, do not treat this as a minor — read the 2.0 upgrade guide first, since the breaking changes landed there, not here.
2. Service provider. Laravel package auto-discovery should register it for you; php artisan about or php artisan package:discover will confirm. If the provider does not appear, you are on a cached manifest — run composer dump-autoload.
3. Publish the config. php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider" --tag=config and read the published file top to bottom. It is the cheapest way to learn the package's actual surface area.
4. First use case. Pick the smallest meaningful operation — a single read, a single dispatch — and run it from php artisan tinker before wiring it into a controller. Establish that credentials, config, and container bindings resolve, then build outward.

Where to look when something is unclear, in order: the published config file, the service provider's register()/boot() (it shows you every binding and singleton), the package's own test suite (it is the most accurate documentation of intended usage), then the README.

Implementation Patterns

Inject the contract, not the facade. Most packages of this shape bind an interface in the container. Type-hint that interface in your constructor and let the container resolve it. Facades are convenient in tinker and in Blade, but constructor injection keeps your classes unit-testable and makes the dependency obvious in code review.

Wrap it in a thin application-level adapter. Rather than calling the package from twenty places, define one small class — App\Support\ThingClient or similar — that owns the package interaction and exposes two or three methods named after your domain. When the package's API shifts (and it will, at the next major), you change one file. This also gives you a natural place to add logging and retries.

Drive behaviour from config, not literals. Anything the package reads from config/<package>.php should be referenced via config() with an env-backed default, so staging and production can differ without a code change. Put your env keys in .env.example at the same time.

Push slow work onto the queue. If the package makes network calls, dispatching a job is almost always the right call from a request path. Give the job its own $timeout that is shorter than the queue worker's --timeout, and set $tries deliberately — a job that retries five times against a rate-limited API will make things worse.

Use fakes in tests, not live calls. If the package ships a fake, swap it in setUp() and assert against recorded interactions. If it does not, bind a stub implementation of the contract in a test-only service provider — this is exactly why you injected the interface. For integration-level coverage, mark those tests with a group (e.g. @group external) so CI can skip them by default.

Pin the major, float the minor. ^2.1 in composer.json, committed composer.lock, and a composer update <vendor>/<package> in its own PR when you want to move. Compatibility releases like this one are low-risk, but they should still be a visible, revertable commit.

Gotchas and Tips

• Laravel 10 raises the floor to PHP 8.1. Adding Laravel 10 support means the package now expects 8.1+ at minimum. If any of your deploy targets still run 8.0, you cannot take this release — check your Docker base image and CI matrix, not just composer.json.
• "Supports Laravel 10" ≠ "only Laravel 10." The constraint is usually widened, not replaced. Verify by reading the actual illuminate/* requirement rather than assuming you must upgrade the framework in lockstep.
• Config caching bites after upgrades. If you use php artisan config:cache in deploy, a newly published or renamed config key will silently return null until you re-cache. Make config:clear + config:cache an explicit deploy step, and never call env() outside config files.
• Test-only PHP 8.2 does not guarantee runtime 8.2. The release notes say tests run on 8.2. That is a signal about CI coverage, not a compatibility promise for your 8.1 runtime. Run your own suite on the PHP version you actually deploy if that differs.
• Deprecation noise on 8.2. PHP 8.2 deprecates dynamic properties. If your app subclasses or extends anything from the package, watch for Creation of dynamic property ... is deprecated in the logs — it usually means a missing #[\AllowDynamicProperties] or, better, an explicit property declaration on your side.
• Debugging resolution failures. When something "just returns null," the usual culprits in order: stale config cache, credentials not reaching the config layer, and a singleton that captured state before you changed the config at runtime. app()->forgetInstance() between test cases if you mutate config.
• Extension points. Before forking, check whether the service provider binds its internals as interfaces or via $this->app->bind() in a way you can override in AppServiceProvider::register(). Rebinding the contract to a decorator that wraps the original is usually cleaner than a fork and survives upgrades.
• Watch the changelog shape. A release consisting only of framework-support and CI changes is a good moment to check whether the maintainers backfill patches to the previous major. If they do not, budget for staying current — otherwise a future security fix may force a surprise major upgrade.