Set Config Resolver Laravel Package

Product Decisions This Supports

• CLI Tool Configuration Flexibility: Enables dynamic, user-customizable configurations for Laravel CLI tools (e.g., custom Artisan commands, standalone scripts) via CLI flags (--config) or embedded PHP configs, reducing friction for end-users and power users.
• Modular CLI Architecture: Supports building composable CLI tools (e.g., plugins, extensions) where configurations can be merged from multiple sources (CLI args, config files, or environment variables), aligning with Laravel’s plugin ecosystem (e.g., Laravel Forge, Envoyer).
• Developer Experience (DX) for CLI Tools: Eliminates boilerplate for parsing CLI flags and merging configs, accelerating development of configurable CLI tools. Reduces cognitive load for developers maintaining complex CLI-driven workflows (e.g., deployment scripts, data migrations).
• Roadmap for Config-Driven CLI Tools: Justifies investing in CLI tools with rich, customizable behavior (e.g., --config=deploy.staging.php) without reinventing config resolution logic. Aligns with Laravel’s growing emphasis on CLI-driven workflows (e.g., Artisan, Laravel Sail).
• Build vs. Buy Decision: Avoids reinventing Symfony’s config resolution for Laravel CLI tools, leveraging a battle-tested open-source component. Reduces technical debt compared to a custom solution, while still allowing for Laravel-specific adaptations.
• Consistency Across Tools: Standardizes config resolution across multiple CLI tools in the codebase, improving maintainability and reducing duplication (e.g., shared config schemas for deployment, testing, or database tools).

When to Consider This Package

• Use Case Fit:
  • Building Laravel CLI tools (Artisan commands or standalone scripts) where users need to override configs via CLI flags (e.g., --config=custom.deploy.php).
  • Tools requiring multi-layered config resolution (e.g., combining default configs, user-provided configs, and environment variables) without manual merging.
  • Projects already using Symfony Console or planning to integrate Symfony components (e.g., for advanced CLI features like argument parsing or help commands).
  • Teams prioritizing developer experience for CLI tools, where reducing boilerplate and improving configurability is a key goal.
• Avoid If:
  • Your CLI tool has simple, static configs with no need for runtime overrides (e.g., a one-off script with hardcoded settings).
  • You’re not using Laravel’s Artisan or Symfony Console, and the dependency overhead is prohibitive (e.g., for a lightweight PHP script).
  • You need advanced config validation beyond basic file/CLI parsing (consider Laravel’s Validator or Symfony’s Config component instead).
  • The archived status of the package is a blocker, and you cannot mitigate risks via forking or wrapping (e.g., for mission-critical tools).
  • You’re targeting Laravel versions < 8.0 or environments where Symfony Console conflicts with other dependencies (e.g., Laravel Sail’s Docker CLI).
  • Your config requirements are web-focused (e.g., API routes, Blade templates) rather than CLI-driven (e.g., Artisan commands, deployment scripts).

How to Pitch It (Stakeholders)

Executives: "This package lets us ship Laravel CLI tools with dynamic, user-customizable configs—like --config=deploy.staging.php—without reinventing the wheel. It reduces development time, improves the experience for teams using our CLI tools (e.g., deployment scripts, data migrations), and aligns with our strategy to build modular, configurable workflows. The risk is low: it’s MIT-licensed, used in production by Symplify’s tools, and we can wrap it in a Laravel-specific adapter to mitigate the archived status. This is a ‘buy’ decision that saves months of dev time and improves DX for our CLI tools."

Engineering (Tech Leads/Architects): *"For Laravel CLI tools needing flexible configs, this package handles:

• CLI flag parsing (--config=file.php) with fallbacks to default configs.
• Merging configs from multiple sources (CLI args, config files, or parameters) without manual work.
• Symfony Console integration, which we already use for Artisan, so no extra dependencies beyond what we have. Tradeoffs:
• The package is archived, but it’s stable and used in production. We’d need to wrap it in a Laravel adapter to handle config precedence (CLI > config files > env vars) and integrate with Laravel’s config() system.
• Adds ~10MB for Symfony Console, but that’s justified if we’re building complex CLI tools. Recommendation: Use this for new CLI tools requiring configurability, and evaluate for existing tools where config management is painful."*

Developers: *"Need to let users override configs via CLI flags in your Artisan command? This package does the heavy lifting:

1. Resolve --config=path/to/file.php into a PHP array with one line:

   $config = (new SetAwareConfigResolver(new MySetProvider()))
       ->resolveFromInputWithFallback(new ArgvInput(), ['defaults.php']);
   

2. Merge it with other configs (e.g., from config/deploy.php or environment variables).
3. Plug it into Laravel’s config() system via a simple adapter. Example workflow:

php artisan deploy:server --config=staging.php

No more manual parsing or merging—just drop this in and go! Gotchas:

• The package is archived, so we’ll need to wrap it to handle Laravel’s config precedence.
• Symfony’s ParameterBag might overwrite Laravel’s configs if not careful—we’ll need to validate the output."*

Product Managers: *"This package enables us to:

• Ship configurable CLI tools faster: No more reinventing config resolution for every new Artisan command or script.
• Improve user experience: Let teams customize workflows via CLI flags (e.g., --config=custom.rules.php) without touching code.
• Reduce support overhead: Standardized config resolution means fewer ‘it doesn’t work’ issues from misconfigured tools. Use it for:
• Deployment tools (e.g., --config=staging.php).
• Data migration scripts with customizable rules.
• Plugin systems where configs need to be merged from multiple sources. Avoid it for:
• Simple scripts with hardcoded configs.
• Web-focused features (use Laravel’s native config() instead). Risk: Low if we wrap it properly—this is a ‘buy’ that saves time and improves DX."*