Laravel Modules Laravel Package

Technical Evaluation

Architecture Fit

• Modular Monolith Pattern: The package aligns perfectly with a modular monolith architecture, enabling teams to decompose large Laravel applications into self-contained, reusable modules (e.g., AuthModule, BillingModule). Each module encapsulates its own:
  • Controllers, models, migrations, policies, and routes.
  • Views (Blade/Inertia/Vue) and assets (CSS/JS).
  • Service providers, events, and commands.
• Namespace Isolation: Modules auto-generate namespaces (e.g., Modules\Auth\...), preventing naming collisions while allowing global access via Laravel’s service container.
• Laravel Ecosystem Compatibility: Seamlessly integrates with Laravel’s core (Eloquent, Blade, Queues, etc.) and third-party packages (e.g., Spatie Media Library, Cashier). Modules can depend on other modules or external packages.
• Microservices Readiness: Modules can later be extracted into standalone services with minimal refactoring (shared database vs. separate services).

Integration Feasibility

• Low Friction Adoption:
  • Zero-configuration setup for basic use (auto-registers service provider/aliases).
  • Optional composer-merge-plugin for autoloading (v11+).
  • Backward-compatible with existing Laravel apps (no core modifications required).
• Tooling Support:
  • Artisan Commands: 30+ commands for scaffolding (e.g., module:make, module:publish, module:seed) and lifecycle management (enable/disable modules).
  • Publishable Assets: Views, migrations, and configs can be published per module.
  • Vite/Laravel Mix: Built-in support for module-specific asset compilation (e.g., resources/js/modules/Auth.js).
• Database Integration:
  • File-Based Activation: Default (storage-based) or Database-Backed Activation (via module:v6:migrate).
  • Shared database schema or module-specific schemas (with route/model binding).

Technical Risk

Key Questions for TPM

1. Modularity Granularity:
   • Should modules align with business domains (e.g., Billing, Inventory) or technical layers (e.g., Auth, Notifications)?
   • Tradeoff: Fine-grained modules reduce coupling but increase boilerplate.
2. Database Strategy:
   • Shared schema vs. module-specific schemas? How will transactions span modules?
   • Example: BillingModule and InventoryModule may need ACID transactions for order processing.
3. Asset Management:
   • Will modules use shared Vite/Laravel Mix or isolated builds? Impact on caching and CDN strategies.
4. Deployment Workflow:
   • Can modules be deployed independently (e.g., zero-downtime updates)? Requires database-backed activation + feature flags.
5. Third-Party Integration:
   • How will modules interact with external APIs (e.g., Stripe, Twilio)? Centralized service layer or per-module integration?
6. Monitoring/Observability:
   • How to attribute metrics (e.g., logs, errors) to specific modules? Consider adding X-Module-ID headers or Laravel tags.
7. Migration Path:
   • For greenfield projects: Start with modules from day 1.
   • For brownfield: Prioritize high-cohesion, low-coupling components (e.g., Auth, Payments) first.

Integration Approach

Stack Fit

• Laravel Versions: Officially supports Laravel 11–13 (PHP 8.1+). Laravel 10 requires v10.x.
• PHP Extensions: No additional extensions beyond Laravel’s requirements (e.g., pdo_mysql, fileinfo).
• Frontend Frameworks:
  • Blade: Native support (module-specific views).
  • Inertia/Vue/React: Works via Laravel Mix/Vite (module-specific asset pipelines).
  • Livewire/Alpine: Requires manual module-specific JS inclusion.
• Database:
  • MySQL/PostgreSQL/SQLite: Full support.
  • MongoDB/Other: Possible via custom module implementations (e.g., Modules\MongoDb\...).
• Queue Systems: Supports all Laravel queue drivers (Redis, Database, etc.) per module.
• Caching: Module-specific cache tags (e.g., cache()->tags(['module-auth'])).

Migration Path

• Route/controller collisions (e.g., Route::get('/login', ...)).
• Shared business logic (e.g., User model used across Auth and Profile modules).
• Database dependencies (e.g., users table shared vs. module-specific). | | Scaffolding | 1. Install package: composer require nwidart/laravel-modules.

2. Publish config: php artisan vendor:publish --provider="Nwidart\Modules\LaravelModulesServiceProvider".
3. Configure composer.json for autoloading (if needed).
4. Run composer dump-autoload. | | Module Creation | Start with high-cohesion, low-coupling components:

php artisan module:make Auth --controller --migration --resource --seed
php artisan module:make Billing --controller --migration --seed

• Use --api for API-only modules (e.g., Billing).
• Use --web for Blade-based modules (e.g., Auth). | | Incremental Refactor | 1. Extract Routes: Move routes from routes/web.php to module-specific RouteServiceProviders.

2. Extract Controllers/Models: Move to module namespaces (e.g., Modules\Auth\Http\Controllers\LoginController).
3. Update Dependencies: Replace use App\Models\User with use Modules\Auth\Models\User.
4. Test Isolation: Use Module::disable('Auth') to test other modules. | | Database Migration | If using database-backed activation:

php artisan module:v6:migrate

• Update config/modules.php to set 'activator' => 'database'. | | Asset Pipeline | Configure Vite/Laravel Mix per module:

// vite.config.js
export default defineConfig({
  build: {
    rollupOptions: {
      input: {
        auth: path.resolve(__dirname, 'resources/js/modules/auth.js'),
        billing: path.resolve(__dirname, 'resources/js/modules/billing.js'),
      },
    },
  },
});
```                                                                                                                                                                                                                                      |
| **Deployment**          | 1. **Feature Flags**: Use Laravel’s `config('modules.enabled')` to toggle modules.
2. **Zero-Downtime**: Deploy module updates independently (if using database-backed activation).
3. **Rollback**: Disable module via `php artisan module:disable Billing` if issues arise.                                                                                                                                                     |

### **Compatibility**
| **Component**            | **Compatibility Notes**                                                                                                                                                                                                 |
|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Laravel Packages**     | Most packages work out-of-the-box (e.g., Spatie Media Library, Laravel Nova). Some may require module-specific configuration (e.g., `config('media-library.disk')` per module).                                      |
| **Middleware**           | Module