Providers Laravel Package

Product Decisions This Supports

• Cleaner Codebase: Adopt this package to decouple service provider and alias definitions from config/app.php, reducing clutter and improving maintainability—especially useful for large Laravel applications with many third-party packages or custom providers.
• Configuration-Driven Development: Align with a configuration-as-code approach, enabling teams to manage service providers and aliases via a dedicated config file (config/providers.php), which can be version-controlled and shared across environments.
• Build vs. Buy Decision: Buy (short-term) for legacy Laravel 5.x projects where config/app.php is already bloated. Avoid reinventing the wheel for minor refactoring needs.
• Roadmap for Modernization: Use this as an interim solution for older Laravel apps before migrating to Laravel 8+ (where config/app.php is already modularized via config/providers.php natively). Justify as a low-risk, quick-win for technical debt reduction.
• Use Cases:
  • Monolithic Apps: Separate core vs. plugin providers (e.g., CMS modules, analytics tools).
  • Multi-Tenancy: Dynamically load tenant-specific providers without modifying app.php.
  • Legacy Migration: Gradually extract providers from app.php during a refactor.

When to Consider This Package

• Adopt If:
  • You’re maintaining a Laravel 5.1–5.3 app with a bloated config/app.php (e.g., >50 providers/aliases).
  • Your team prioritizes configuration clarity over minimalism (e.g., devs frequently search for providers).
  • You need a quick, no-code-change solution to externalize provider definitions (vs. manual refactoring).
• Look Elsewhere If:
  • You’re using Laravel 8+: Native support for config/providers.php obviates this package.
  • Your app is small or greenfield: The overhead of adding a package isn’t justified.
  • You need dynamic provider loading: This package is static; consider event-based solutions (e.g., ServiceProvider::booting()) for runtime flexibility.
  • Active Maintenance: The package is archived (2016) and unsupported. Evaluate risks for long-term projects.
  • Alternatives Exist: For Laravel 5.x, consider:
    • Manual refactoring (lower risk for small teams).
    • Custom config files + autoloading (e.g., config/providers.php manually included in app.php).
    • Upgrading to Laravel 8+ for built-in support.

How to Pitch It (Stakeholders)

For Executives: "This package lets us clean up technical debt in our Laravel 5.x app by moving 30+ service providers out of config/app.php into a dedicated config file. This reduces merge conflicts, improves readability, and makes onboarding easier—all with a one-time setup (no ongoing maintenance). It’s a low-cost, high-impact fix for a legacy pain point, costing ~2 hours to implement vs. weeks of manual refactoring. We’ll phase it into our 2024 modernization roadmap alongside other Laravel upgrades."

For Engineering: *"We’re proposing this minimalist package to externalize service providers/aliases from app.php into config/providers.php. Benefits:

• No breaking changes: Just publish the config and update app.php once.
• Future-proof: Mimics Laravel 8+’s native behavior, easing eventual upgrades.
• Risk-mitigated: Static config means no runtime surprises; easy to roll back. Tradeoff: The package is abandoned, but since it’s a config-only change, we can fork it if needed. Alternative is manual refactoring (higher effort). Recommend a POC in a staging environment first."*

For Developers: *"This package lets you offload providers/aliases to config/providers.php, so app.php stays lean. Example:

// Before (app.php)
'providers' => [
    App\Providers\AppServiceProvider::class,
    Laravel\Cashier\CashierServiceProvider::class,
    // ...50 more lines...
],

// After (config/providers.php)
return [
    'providers' => [
        App\Providers\AppServiceProvider::class,
        Laravel\Cashier\CashierServiceProvider::class,
        // ...now in a separate file!
    ],
];

Steps:

1. composer require juy/providers:1.*
2. Add Juy\Providers\ServiceProvider::class to app.php.
3. Publish config: php artisan vendor:publish --provider="Juy\Providers\ServiceProvider" --tag="config". Caveat: Package is old, but the change is safe. If issues arise, we can manually merge the logic."*