Config Laravel Package

Product Decisions This Supports

• Build vs. buy for DI/config plumbing: 6.1.0 strengthens the case for adopting this package rather than hand-rolling a container and config loader. Definition::addConfigDirectory() delivers layered, multi-directory config loading with merge semantics (later directories override earlier), which is exactly the "ship defaults, let the app override" pattern every framework package re-implements poorly in-house.
• Framework/SDK packaging strategy: If we ship a Laravel package or internal framework layer, this release directly supports the "package ships default config, host project overrides" roadmap item without bespoke merge code. Lowers the cost of making our packages configurable and upgrade-safe.
• Feature: config extensibility: Enables a "sensible defaults + project overrides" feature set (per-environment config, package presets, tenant overrides) with predictable precedence ordering. This is a differentiator we can put in front of customers as configurability without footguns.
• Roadmap risk reduction: DependencyInjection API improvements and added validations reduce the likelihood of silent misconfiguration in production — a common source of support tickets and incident toil.
• Use cases unlocked: framework packages shipping defaults; multi-environment deployments needing layered config; modular/monorepo apps where each module contributes config; internal platforms standardizing DI across services.
• Migration/debt decision: Since there is no prior assessment, treat this as a fresh adopt/not-adopt gate. The layered-config capability is the primary reason to adopt now rather than defer.

When to Consider This Package

Adopt when:

• We are building or maintaining a Laravel/PHP package that needs default config overridable by the host project — 6.1.0 is purpose-built for this.
• We have multiple config sources (module config, environment config, tenant/override config) and need deterministic precedence and merge behavior.
• Our teams are duplicating config-merging or container-wiring logic across services and we want a single, validated dependency-injection path.
• We value explicit validation in the DI layer to catch wiring errors early (the new validations in 6.1.0 help here).

Look elsewhere when:

• We are fully committed to Laravel's native service container and config/ publishing conventions and do not need multi-directory layered loading — adopting adds a parallel abstraction.
• Requirements are trivial (single config file, no overrides); the added conceptual surface isn't justified.
• We need config loading guarantees beyond merge/precedence (e.g., hot reload, remote config, secrets management) — evaluate dedicated config/secret tooling instead.
• Team familiarity with a competing DI standard (e.g., PSR-11 container already in use) makes switching cost exceed the benefit.

Before committing, verify: exact override precedence semantics match our expectations, behavior of deep vs. shallow merges for nested arrays, performance of multi-directory loading at boot, backward-compatibility of the DependencyInjection API changes for any existing consumers, and test coverage for the new merge paths.

How to Pitch It (Stakeholders)

For executives: This release lets our PHP/Laravel packages ship with sensible default configuration that customers and internal projects can override cleanly — a small upgrade that removes custom glue code, reduces misconfiguration incidents, and makes our packages easier to adopt and configure. Low integration cost, contained scope, no new vendor dependency.

For engineering: 6.1.0 adds Definition::addConfigDirectory() for layered multi-directory config loading with full merge support (later directories override earlier), enabling the standard "package defaults, project overrides" pattern without bespoke code. It also tightens the DependencyInjection API with improved validations, catching wiring errors earlier. Recommended action: spike adoption in one package, confirm merge/precedence semantics and boot-time cost, then standardize. Watch for any behavior changes in the DI API that affect existing consumers before rollout.