- How do I load Laravel service providers only in local or staging?
- sven/env-providers lets you declare a provider list keyed by application environment, so packages like Debugbar, Telescope, Ignition, and IDE Helper only register where you want them. It hooks Laravel's provider-registration step during bootstrap and merges your environment-scoped list into the standard config/app.php or bootstrap/providers.php set. That keeps environment policy in one declarative file instead of scattering app()->environment() checks through your service providers.
- How do I install sven/env-providers?
- Install it with Composer using composer require sven/env-providers. It is MIT licensed, has no native extensions or external services, and is an application-level package, so it belongs in a single Laravel app rather than a shared internal package that other projects consume. Check the repository README for the current config publishing step and tag, since the README contents were not available in this summary.
- Which Laravel and PHP versions does sven/env-providers support?
- It requires a full Laravel application rather than Lumen, plus a modern PHP constraint and an illuminate/support version that matches your pinned framework release. The last tagged release was 2024-10-23, so verify the exact constraints in the package composer.json against your Laravel major before adopting. If you run a very recent Laravel major, confirm compatibility or be prepared to submit a pull request.
- Is sven/env-providers compatible with config:cache and artisan optimize?
- This is the main thing to prove before adopting: whether your environment provider list is compiled into the config cache or re-read at boot. The package merges an environment-scoped provider list into the standard provider set during bootstrap, but caching behavior is not documented in the available material. Write a boot test per environment that runs config:cache, route:cache, and optimize, then asserts the expected providers are registered and the debug ones are not.
- Is sven/env-providers safe to use in production?
- Be careful with the direction of failure. If a debug provider registers because APP_ENV was misconfigured on a cloned preview or staging environment, you have exposed debugging tooling in production. A safer pattern is deny-by-default: explicitly allowlist the providers that may load in production and assert that in a CI test. Also add a deployment check that fails when APP_ENV does not match an expected value.
- How is sven/env-providers different from checking app()->environment() in AppServiceProvider?
- Laravel's native idiom is an if ($this->app->environment('local')) { $this->app->register(DebugbarProvider::class); } block inside AppServiceProvider::register(), or a PHP-computed providers array in bootstrap/providers.php. That works, but it scatters environment policy across the codebase as environments multiply. This package centralizes the policy into one declarative file, which is a real readability and auditability win once you have three or more environments with materially different provider sets.
- What happens if APP_ENV is unset or set to an unexpected value?
- The documented fallback behavior is not stated in the available material, and this matters because falling through to the base provider list could register development tooling in production. Treat an unset or unrecognized APP_ENV as a failure, not a default. Add a bootstrap assertion or a PHPUnit test that boots the application with each expected environment value and verifies which providers registered.
- Does sven/env-providers affect service provider registration order or deferred providers?
- Provider registration order is load-bearing, because a provider's register() method may depend on a binding from an earlier provider, and deferred providers are compiled into a manifest during artisan optimize. Because the package intercepts or appends to Laravel's registration step, ordering semantics become its responsibility. Before adopting, ask the maintainer where it injects, whether it uses a custom bootstrapper, a RegisterProviders override, or a listener, and test ordering explicitly.
- Does sven/env-providers work with Laravel Octane and package discovery?
- Octane keeps the application booted between requests, so environment-scoped providers are resolved at worker boot rather than per request, which is usually the behavior you want. What still needs confirming is whether the package participates in Composer package discovery or requires explicit opt-in per provider. Verify with artisan about and a boot test under Octane that the same provider set registers in each environment.
- Is sven/env-providers still maintained, and should I fork it instead?
- The repository has roughly 76 stars, zero dependents, a single maintainer, and a last release in October 2024, so no ecosystem has stress-tested its edge cases. The upside is that the code surface is small, essentially a bootstrapper plus a config reader, so you can review it in an afternoon or fork and vendor it under the MIT license. If you adopt it, decide up front who owns Laravel major-version compatibility and keep a fork plan ready.