Modular Laravel Package

Product Decisions This Supports

• Feature Development: Enables modular architecture for Laravel apps, allowing teams to:

  • Isolate features (e.g., "Payments," "User Profiles," "Analytics") into self-contained modules with their own:
    • Routes (routes/)
    • Migrations (database/)
    • Views (resources/)
    • Tests (tests/)
    • Commands, policies, and providers.
  • Decouple tightly coupled code (e.g., separate a legacy monolith into modular services).
  • Accelerate development by reusing module templates (e.g., scaffold a new "Blog" module with make:module).

• Roadmap Prioritization:

  • Build vs. Buy: Justify not using nwidart/laravel-modules (which adds complexity) in favor of a lighter-weight, Laravel-native solution.
  • Tech Debt Reduction: Replace ad-hoc directory structures (e.g., app/Features/Payments/) with standardized modules for easier maintenance.
  • Scalability: Prepare for microservices decomposition by treating modules as potential future services.

• Use Cases:

  • Large-Scale Applications: Organize monolithic apps (e.g., SaaS platforms) into modular components.
  • Team Collaboration: Enable parallel development by teams working on independent modules (e.g., frontend vs. backend).
  • Third-Party Extensions: (Limited) Allow vendors to contribute modules via Composer (though dynamic enabling/disabling is weaker than laravel-modules).
  • Legacy Refactoring: Gradually modularize an existing app without rewriting everything.

When to Consider This Package

Adopt if:

• Your Laravel app is growing in complexity (50+ routes, 10+ tables, or multiple feature teams).
• You want Laravel-native modularity without deviating from framework conventions (e.g., no custom directory structures).
• Your team prioritizes simplicity over advanced features like dynamic module enabling/disabling.
• You’re using Laravel 9+ and need Blade components, translations, and event discovery support.
• You plan to extract modules into standalone packages later (customizable namespace prefixes help).

Look elsewhere if:

• You need dynamic module enabling/disabling (e.g., a CMS or plugin system) → Use nwidart/laravel-modules.
• Your app uses Laravel <9 or requires PHP <8.0 (this package drops legacy support).
• You need advanced module dependencies (e.g., Module A requires Module B to load).
• Your team lacks Composer path repository familiarity (setup requires manual composer.json edits).
• You’re building a multi-tenant SaaS where modules must be isolated per tenant (this package doesn’t enforce tenant isolation).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us organize our Laravel app like LEGO blocks—breaking it into reusable modules (e.g., Payments, Notifications) that teams can develop independently. It’s not a rewrite, but a scalable upgrade to our current structure, reducing technical debt and speeding up feature delivery. Think of it as containerizing parts of our app without the complexity of microservices. Competitors like [nwidart/laravel-modules] add bloat; this stays lightweight and Laravel-native, so our devs won’t fight the tooling."

Key Outcomes:

• Faster onboarding for new features (pre-built module templates).
• Easier maintenance (isolated codebases for modules).
• Future-proofing for potential microservices (modules can become standalone packages).

For Engineering:

*"This replaces our hacky app/Features/ folders with a standardized, Laravel-approved module system. Here’s why it’s better than rolling our own:

• Zero framework violations: Uses Laravel’s package discovery and Composer path repos—no black magic.
• Full Laravel integration: Modules auto-register routes, migrations, Blade components, events, and even Livewire (if installed).
• Dev tooling: Add --module=Payments to any make: command (e.g., make:controller --module=Payments) to scaffold into the right namespace.
• IDE-friendly: Syncs with PhpStorm to avoid duplicate module paths.

Trade-offs:

• Not as feature-rich as laravel-modules (no dynamic enabling/disabling), but simpler and faster for our use case.
• Requires a one-time composer.json setup (path repos + module dependencies).

Next Steps:

1. Pilot: Create 2–3 modules (e.g., Auth, Reports) and compare dev velocity to our current approach.
2. Onboard: Run php artisan modules:sync to auto-configure PhpStorm and PHPUnit.
3. Gradual Migration: Move one feature at a time into modules during sprints."*

For Developers: *"You’ll love:

• make:module → Instant scaffold for new features.
• <x-module::component /> → Blade components with namespaced paths.
• __('module::translations.key') → Easy i18n per module.
• No config hell: Just composer require internachi/modular and go.

Gotchas:

• Modules live in app-modules/, not app/.
• Windows paths? Fixed. Livewire? Supported. Laravel 11? Check.
• Want to extract a module later? Customize the namespace prefix in config/modular.php."*