Env Providers Laravel Package

Product Decisions This Supports

• Environment-scoped feature rollout: Decide that integrations such as debug bars, query loggers, Ray/Telescope-style tooling, mock payment or mail drivers, and staging-only observability agents should be declared per environment rather than guarded by scattered if (app()->environment('local')) checks. This turns "which providers run where" into reviewable configuration instead of hidden control flow.
• Build vs. buy: The capability is ~30–50 lines of code (read a config array, loop, $this->app->register()). The decision is therefore not "can we build it" but "do we want a shared, documented convention for it." Buying/adopting costs nothing (MIT), but earns a micro-dependency; building earns ownership and zero vendor risk. v4.2.0 does not change this calculus — it is a compatibility release, not new capability.
• Config-cache correctness: Provides a config-file-driven mechanism, avoiding raw env() calls inside config/app.php — a recurring source of production breakage after php artisan config:cache. This is a reliability decision as much as an ergonomics one.
• Test-suite performance and isolation: Providers that boot HTTP clients, queues, or external SDKs only when the environment matches keeps the testing environment lean and deterministic — directly supports roadmap work on CI duration and flaky-test reduction.
• Blast-radius reduction for production: Production-only providers (monitoring, audit logging, error reporting) can be registered without also booting in local or CI, and dev-only providers cannot leak into production by accident.
• Laravel 11+ upgrade path (new in v4.2.0): The package now declares Laravel 11 support. This removes a previously blocking objection and means the "declarative per-environment providers" convention can be carried through our framework upgrade rather than being retired as part of it.
• Use cases: multi-environment deployments (local/staging/prod/QA), teams accumulating third-party integrations, on-prem or enterprise builds with environment-specific wiring, and any app where provider registration has become a grab-bag.

When to Consider This Package

Adopt when:

• You already have three or more providers that are strictly environment-specific; below that threshold, a conditional in AppServiceProvider::register() is clearer and dependency-free.
• Your provider list mixes unconditional entries with env()-dependent conditionals, or you have been bitten by config caching.
• You maintain distinct local/staging/production provider sets and want that reviewed in diffs.
• You are on Laravel 11 and still want declarative per-environment provider loading. v4.2.0 (PR #70) adds Laravel 11 compatibility, so the version-range objection that applied at v4.1.0 no longer blocks evaluation — but verify your minor version is inside the newly declared support range before committing.
• Your team accepts small, single-purpose MIT packages and can pin versions.

Look elsewhere or skip when:

• Dependency governance is strict. Low star count, effectively no known dependents, a single maintainer, and a ~9-month release gap before this version mean this remains a vendor-risk micro-dependency, not a platform bet. Replicating the behavior in-house is a short, low-risk task. Note also that the bulk of v4.2.0 is Dependabot CI noise; the one substantive change came from an outside contributor, not the maintainer — treat maintainer responsiveness as unproven.
• You need per-tenant, per-request, or feature-flag-driven provider loading — this package keys off environment only.
• You require guaranteed provider ordering relative to other providers; verify this explicitly, since boot order affects event listeners and bindings.
• You are standardizing exclusively on Laravel 11's bootstrap/app.php registration surface (->withProviders()) and want a single, framework-native place to declare providers. The package's original premise assumes a config/app.php providers array; confirm exactly where and how it hooks in under Laravel 11 before adopting, since two registration surfaces is worse than one.
• The problem is really "too many providers" — the answer may be consolidation or deferred providers, not conditional loading.

How to Pitch It (Stakeholders)

For executives: A small, free (MIT) utility that lets us declare which Laravel service providers load in which environment. It removes a class of production incidents — dev tooling or test-only integrations booting where they shouldn't — and fixes a known fragility around config caching. The v4.2.0 release is a low-risk compatibility update: it adds Laravel 11 support, which means the convention survives our framework upgrade instead of being thrown away, and it carries no breaking changes. Cost remains effectively zero, there is no infrastructure change, and it is removable in an afternoon. The caveats are unchanged: low-adoption community package, single maintainer, and a release history that is mostly automated dependency bumps — so we pin the version and keep a ~40-line in-house fallback ready.

For engineering: v4.2.0 is a minor release — Dependabot CI bumps plus Laravel 11 compatibility (PR #70). Upgrade is a composer bump with no migration work. The architectural point stands: move environment-conditional providers out of config/app.php / AppServiceProvider into a dedicated config file keyed by environment. Benefits: config stays cache-safe (no env() at config load), provider registration becomes declarative and diff-reviewable, and the testing environment stops booting heavyweight providers. Two things to check on the way in: (1) on Laravel 11 the provider list lives in bootstrap/app.php, so confirm the package's entry point doesn't leave you maintaining providers in two places; (2) provider ordering relative to other providers — boot order affects event listeners and bindings. Migration is mechanical — list the providers, delete the conditionals — and rollback is reverting one file.

Ask: A half-day spike to move our existing environment-conditional providers behind this config on the v4.2.0 tag, with a documented fallback path if the package goes stale again.