- How do I install percymamedy/laravel-dev-booter in a Laravel app?
- Install it with Composer using composer require percymamedy/laravel-dev-booter, then publish its config file with php artisan vendor:publish. Move your dev-only service providers out of config/app.php or bootstrap/providers.php and list them in the package config. After editing, run php artisan config:clear and php artisan package:discover to confirm the providers are picked up. Start with one low-risk provider before migrating the rest.
- Which Laravel and PHP versions does laravel-dev-booter support?
- Support depends on the Composer constraints declared in the package, so check those against your target Laravel and PHP versions before adopting. The last release was in July 2024, so verify compatibility explicitly on Laravel 11 and 12 rather than assuming it. Run a quick install on a branch and confirm providers load correctly before committing to it. If constraints block you, the MIT license allows forking or vendoring the small amount of logic involved.
- Does laravel-dev-booter work with Laravel 11 bootstrap/providers.php?
- Laravel 11 changed how providers are bootstrapped, and the package predates some of those changes, so test this directly rather than assuming it works. If it does not integrate cleanly, the native alternative is conditional registration inside a service provider or careful editing of bootstrap/providers.php. Confirm the package does not keep auto-discovering a provider you intended to disable. Compare php artisan about provider output across environments to be sure.
- Is laravel-dev-booter safe to use with config caching and route caching?
- Environment-conditional provider registration must work when configuration is cached, so test php artisan config:cache and php artisan route:cache before deploying. A stale config cache is one of the main failure modes, so clear caches after every provider change. If registration depends on runtime environment detection, confirm it still resolves correctly with cached config. Add a smoke test that asserts expected providers are present in each environment.
- Can laravel-dev-booter register providers for multiple environments like local, testing, and staging?
- Yes, the intent is to map providers to environments such as local, testing, and staging through configuration. The real risk is parity: a provider treated as dev-only but required in staging or production will fail late and loudly. Classify each provider deliberately as all-environment, dev-only, or production-only and document the decision. Use provider-list diffs between environments as a release gate.
- Does laravel-dev-booter support aliases, facades, and deferred providers?
- Aliases, facades, and deferred providers depend on correct load order and registration timing, so verify each case in your app. Deferred providers are especially worth testing because they only register when their bindings are resolved. If a facade breaks, check whether the provider still registers before the facade is used. A quick test that resolves the facade in each environment will catch most ordering problems.
- How is laravel-dev-booter different from conditional provider registration in AppServiceProvider?
- It centralizes environment-conditional provider registration in configuration instead of scattered if checks, which is convenient when you carry many dev-only packages. It does not add new capability; the same result is achievable natively with $this->app->register() guarded by environment checks. If your app already has clean native conditional registration, adding this dependency may not be worth the maintenance risk. Adopt it only when provider sprawl is a genuine pain point.
- Is percymamedy/laravel-dev-booter actively maintained and production ready?
- The project has around 35 stars, a likely single-maintainer pattern, and a last release in July 2024, so treat it as a low-support dependency. It is a small, low-complexity utility, but it still needs an internal owner and documentation. Pin the version, monitor releases, and be ready to fork or replace it with native Laravel conditionals. Do not assume upstream responsiveness or an SLA.
- How do I migrate providers like Debugbar or IDE Helper to laravel-dev-booter?
- First inventory every registered provider and classify each as all-environment, dev-only, or production-only. Install the package on a non-production branch, publish its config, and migrate a single dev-only provider such as Debugbar. Run php artisan config:clear, php artisan config:cache, and php artisan package:discover, then compare php artisan about provider lists against the previous behavior. Once that provider behaves correctly, migrate the remaining ones in small batches.
- How do I roll back or replace laravel-dev-booter with native Laravel code?
- Rollback means reverting the Composer changes and restoring your original provider registration in config/app.php or bootstrap/providers.php. The native replacement is straightforward: conditionally call $this->app->register(YourProvider::class) inside a service provider based on the current environment. Because the underlying logic is small and the license is MIT, you can also vendor a private copy if you want the convenience without the dependency. Document the rollback steps before you migrate providers so recovery is quick.