ritaswc/laravel-query-logger
Laravel Query Logger records the SQL queries your application runs, capturing statements, bindings, execution time, and where they originated. Use it to debug slow pages, spot N+1 queries, and audit database activity during development or in production.
The 2.2.0 release is a compatibility release: it widens the supported Laravel framework range. That is the single most important thing to know before you start, because it changes where you look first — not how the package behaves.
First steps
composer.json and check the require block for illuminate/*, laravel/framework, and php. The functional surface of 2.2.0 is the version range itself; everything you can do with the package is whatever it did in the 2.x line, now permitted on newer Laravel.composer why-not vendor/package 2.2.0 in an app pinned to the older release. If it resolves, the upgrade is a composer update vendor/package away. If it does not, the message names the exact conflicting constraint, which is the whole diagnosis.ServiceProvider under src/ (or a Providers/ directory), and check whether it is deferred. Then look for config/ files, publishable assets, migrations, and any facade in the aliases block. That inventory is your map of the package's surface area.A sensible first use case: install on your newest Laravel app (the version 2.2.0 unlocked for you), publish any config, run the documented happy path once end-to-end, and then run your app's test suite. That single loop tells you both "does it work here" and "does it break the rest of my dependency graph."
Because 2.2.0 adds framework versions rather than features, the patterns below are about holding a working integration steady across a widening support matrix.
Pin the range, float the patch. Require the package with a constraint that expresses your real intent, e.g. "^2.2" rather than an exact 2.2.0. You want future compatibility patches to arrive without a manual bump, while still refusing a 3.x that could change behaviour. Combine this with a committed composer.lock so CI and production agree.
Test one job per Laravel version. If you support several framework versions, use a CI matrix (GitHub Actions shuffle: true on the PHP/Laravel axis is a common choice, or orchestral/testbench for a package's own suite) with one job per supported Laravel version and the lowest PHP you claim to support. A compat bump is exactly the kind of release where the lowest supported combination breaks — highest-and-newest testing hides it.
Isolate the package behind your own seam. For anything you call in more than one or two places, wrap it in a small app-level service or adapter class and bind it in a service provider. When a future release does change behaviour (2.2.0 suggests upstream churn is happening), you edit one class instead of grepping the codebase. This is cheap insurance and pays for itself at the next major bump.
Resolve from the container, not statically. Prefer constructor injection of the package's contracts/classes over calling facades inside domain code. It keeps the package swappable in tests and avoids the classic trap where a facade is aliased in config/app.php but not registered in the test bootstrap.
Publish deliberately, then own your copy. Publish config and migrations once, commit them, and treat them as application code. If you leave them unpublished and rely on the vendor defaults, a future version's changed default silently alters your runtime behaviour.
Upgrade as a discrete, reversible change. Run composer update vendor/package --with-dependencies, then immediately: clear caches (php artisan config:clear, route:clear, view:clear), run migrations in a scratch environment, and run the test suite. Keep it in its own commit or its own PR so a revert is one click.
Never trust a stale config cache. Laravel caches configuration aggressively. After any version bump, php artisan config:clear before you conclude "the package is broken." A surprising share of post-upgrade bug reports are a cached config array and a deferred service provider disagreeing.
Deferred providers and config reads. If the service provider is deferred, it only loads when a bound service is resolved. Reading the package's config in code that runs before that resolution can yield null rather than the default. Publish the config, or resolve the service explicitly early in the request lifecycle.
Constraint conflicts usually aren't the package's fault. composer why-not output often points at a third dependency — a locked transitive illuminate/support, an old test runner, or a PHP version floor — not at the package. Read the tree before you file anything upstream.
PHP floor moves with the framework floor. Newer Laravel majors raise the minimum PHP. If 2.2.0 allows a newer Laravel, that Laravel may require a newer PHP than your CI matrix uses. Bump the php constraint in your own composer.json deliberately rather than letting it drift.
Facade aliases and package discovery. If the app uses package auto-discovery, do not also register the provider manually — you get double registration and occasionally duplicate event listeners or route definitions. If you have "dont-discover" configured, verify the provider still loads after the upgrade.
Deprecations surface at the seams. Framework compat releases frequently mean internal use of APIs that newer Laravel deprecates. Turn on deprecation reporting in CI (for example SYMFONY_DEPRECATIONS_HELPER=weak in PHPUnit, or a deprecation-to-log channel) so you learn about these from your own suite rather than from a production log.
Extension points worth auditing now. Even without feature changes, verify these still work post-upgrade: published config merge behaviour, any custom drivers/managers the package exposes, published migrations and whether they still run cleanly on a fresh database, and any Blade views you've overridden with vendor:publish --tag=.... These are the places a compat bump quietly breaks.
Keep a rollback path. Pin the previously working version in a branch, or record it in the lockfile history. composer require vendor/package:2.1.* should be a one-line recovery if 2.2.0 exposes an issue only on a framework version you don't exercise locally.
Watch for the follow-up release. A narrow "support later framework versions" note often precedes a patch that fixes something found on the new version. Stay on ^2.2 and let patches land; read the changelog for 2.2.x before doing another manual upgrade.
How can I help you explore Laravel packages today?