Stacked Dumper Laravel Laravel Package

Getting Started

The v1.10.0 release shifts the support matrix rather than adding API surface: Laravel 13.x is now supported, and the minimum moves to Laravel ^11.0 (Laravel 10 is off the table). Treat this as a compatibility release and verify your app's Laravel version before anything else.

1. Confirm your floor. You need Laravel ^11.0+ and a PHP version your framework supports. If you're still on Laravel 10, composer require will fail to resolve — stay on the previous tag (^1.9) until you upgrade the app, then bump.
2. Install and publish. composer require the package, then publish its config/migrations (php artisan vendor:publish --provider="...\ServiceProvider" or the tagged variant the README documents) and run php artisan migrate if it ships schema.
3. Look first at the README's quickstart, the package config file (config/<package>.php), and the service provider's register()/boot() — that tells you what is bound into the container and what is configurable. The changelog is short here, so the provider is the real source of truth.
4. First use case: resolve the package's main entry point out of the container in a Tinker session or a throwaway route, exercise the simplest call it offers (a lookup, a dispatch, a render), and confirm the result before wiring it into a controller. That single round-trip validates config, credentials, and provider registration in one shot.

Because Laravel 13 support is brand new in this release, do that first-use smoke test on your target framework version rather than assuming it behaves identically to 11/12.

Implementation Patterns

• Inject, don't instantiate. Resolve the package's services via constructor injection or app(...) so you inherit whatever the provider configures. new-ing the class yourself bypasses config and any decorators the package registers.
• Facades are for controllers and Blade; injection is for services. If the package exposes a facade, keep it at the edges of your app so tests can swap the underlying binding.
• Config over code. Publish the config file, put environment-specific values in .env, and reference them from the config array — never read env() from your own classes, or config:cache will bite you.
• Wrap it behind your own interface. Even a thin adapter class (App\Contracts\... + one implementation delegating to the package) makes the next major-version bump a one-file change and keeps the package out of your domain code.
• Testing. If the package ships fakes, use them; if not, bind a mock of your adapter in the container during tests. For anything that hits the network, prefer Http::fake() at the boundary and assert on the package's outputs, not its internals.
• Queues and long-running processes. If the package dispatches jobs or registers singletons with request state, restart queue workers and Octane workers on deploy — the upgrade guidance applies doubly when the underlying framework minor changes.
• Upgrade workflow for this release: bump to ^1.10 only once the app is on Laravel 11+, run the full suite, then run it again on the newest Laravel you intend to support. Keep the bump in its own PR so a resolution failure is easy to revert.

Gotchas and Tips

• Dropping Laravel 10 is a hard break for downstream users. Composer will simply refuse to resolve; there's no deprecation period. Pin ^1.9 in apps you can't upgrade yet and note it in your dependency audit.
• "Laravel 13 support" means tested-against, not battle-tested. Third-party ecosystem packages often lag. Check that your other dependencies also declare 13.x before moving the whole app.
• The PHP 8.5 / Composer 2.10 bumps are dev-container changes, not runtime requirements. They affect the package's CI, not your application's PHP version — don't infer a PHP floor from them; read composer.json's require block for the real constraint.
• Config caching is the usual culprit when behavior differs between artisan tinker and the web app: run php artisan config:clear (and optimize:clear) after touching the published config.
• Resolution debugging: composer why-not vendor/package 1.10.0 tells you which constraint is blocking the upgrade — usually a transitive dependency pinning an older Laravel or PHP.
• Provider not loading? Check package discovery in bootstrap/providers.php (Laravel 11+) or config/app.php, and confirm you haven't cached a stale bootstrap/cache/services.php.
• Extension points worth knowing: published config (drivers, timeouts, feature flags), container bindings you can override in a service provider, and any events the package dispatches — listening to those is often cleaner than forking behavior.
• Pin minor versions in production ("^1.10" rather than "*") and commit the lock file; this release is a good reminder that a "minor" bump can carry a framework-floor change.