Laravel Auto Reg Laravel Package

Product Decisions This Supports

• Non-standard project structures: Enables teams to adopt modular, domain-driven, or microservice-like architectures within Laravel without sacrificing convention-based autoloading/registration.
• Build vs. Buy: Avoids reinventing custom registration logic for custom directory layouts, reducing technical debt and developer onboarding time.
• Developer Experience (DX): Accelerates onboarding for new team members by eliminating manual configuration of providers, aliases, routes, etc., in config/app.php.
• Roadmap for monorepos: Supports teams migrating from monolithic Laravel apps to modular monorepos (e.g., splitting by feature/domain) without breaking Laravel’s core workflows.
• Multi-tenant or plugin architectures: Simplifies dynamic registration of tenant-specific providers, routes, or configs without hardcoding paths.
• Legacy system modernization: Enables gradual refactoring of legacy Laravel apps with deeply nested or non-standard directory structures.

When to Consider This Package

• Adopt when:

  • Your team uses a non-standard Laravel directory structure (e.g., app/Modules/, src/, or domain-driven layouts like app/Users/, app/Orders/).
  • You’re building a modular monolith or planning to split a Laravel app into microservices but want to retain Laravel’s conventions.
  • Onboarding velocity is critical, and manual registration of providers/routes in config/app.php is a bottleneck.
  • You need to dynamically register components (e.g., plugins, tenant-specific configs) at runtime without hardcoding paths.
  • Your team prefers declarative over imperative configuration (e.g., defining structure in composer.json or config files).

• Look elsewhere if:

  • Your project strictly follows Laravel’s default directory structure (no need for custom registration).
  • You require fine-grained control over registration order/dependencies (this package abstracts that away).
  • Your team lacks composer.json configuration discipline (package relies on explicit directory mappings).
  • You’re using Laravel 7 or below (package supports 8+).
  • You need advanced runtime registration (e.g., conditional loading based on environment or user roles) beyond what the package offers.

How to Pitch It (Stakeholders)

For Executives/Product Leaders:

*"This package solves a critical friction point for our Laravel teams: scaling without sacrificing developer velocity. By automating the registration of service providers, routes, and configs—even in custom directory structures—we eliminate manual boilerplate that slows down feature delivery. For example:

• Modular monoliths: Teams can organize code by domain (e.g., app/Payments/, app/Users/) without breaking Laravel’s conventions, accelerating migration to microservices later.
• Faster onboarding: New hires won’t waste days configuring config/app.php; they’ll focus on building features.
• Reduced technical debt: Avoids custom scripts or hacks to handle non-standard layouts.

Investment: Minimal (MIT-licensed, low-maintenance). ROI: Hours saved per developer per sprint, especially for teams with 5+ engineers. Recommend adoption for projects with custom directory structures or modular ambitions."*

For Engineering Leaders/Architects:

*"Problem: Laravel’s convention-over-configuration works beautifully for standard structures, but custom layouts (e.g., domain-driven, plugin-based, or monorepo setups) force teams to:

• Manually register providers/routes in config/app.php.
• Maintain custom autoloading rules.
• Risk breaking changes during refactoring.

Solution: laravel-auto-reg automates this by:

1. Scanning directories (defined in composer.json or config) for Laravel components (providers, routes, migrations, etc.).
2. Dynamically registering them in the correct order, with zero manual config/app.php edits.
3. Supporting runtime flexibility: Ideal for plugins, multi-tenancy, or feature flags where components load conditionally.

Why now?

• Monorepo migration: If we’re splitting the app into modules (e.g., app/Orders/, app/Inventory/), this prevents registration spaghetti.
• Plugin ecosystem: For [Project X], we need to load tenant-specific configs dynamically—this handles it cleanly.
• DX win: Developers spend less time configuring, more time shipping.

Risks:

• Assumes discipline in composer.json configuration (but this is a best practice anyway).
• Not a replacement for advanced dependency management (e.g., circular provider dependencies).

Recommendation: Pilot with the [Modular Monolith] team. If successful, roll out to projects with non-standard structures. Pair with a doc update on composer.json best practices for auto-registration."*