Laravel modules with Tenancy for laravel

[DawidMazur]

How can I set up that migration for specific module will be migrated only for tenant database. I can set up behavior that is loading it on tenant (in config of tenancy), but I can't skip migrations for main database without changes directly in modules.

[Kikiabdilah]

To ensure that migrations from specific modules are only executed on the tenant database (and not on the main database) when using nWidart/laravel-modules with Tenancy for Laravel, you can consider these approaches without modifying the migration files inside the modules:

Tagging Migrations or Naming Convention
Place tenant-specific migrations in a dedicated folder or use a naming convention, e.g., Modules/Blog/Database/Migrations/tenant/.
When running tenant migrations, only load migrations from this path.

Custom Migration Command in Tenancy
In your tenancy config (tenancy.php), set migrations_paths to only include migrations meant for tenants:

'migrations_paths' => [
    database_path('migrations/tenant'),
    base_path('Modules/Blog/Database/Migrations/tenant'),
    // ...add other paths as needed
],

This way, when you run artisan tenants:migrate, only these migrations will be executed.

Skip Migration on Main Database
Make sure that when running main database migrations (php artisan migrate), the tenant migration folders are not included in the migrations config in database.php or are otherwise not loaded by that command.

Customize the Module Service Provider (Optional)
For an advanced solution, you can override the registerMigrations() method in the module’s service provider to only register migrations when in a tenant context (e.g., by checking if a tenant is active).

Example Implementation:

// In your module's service provider
public function boot()
{
    if (tenancy()->check()) {
        $this->loadMigrationsFrom(__DIR__.'/../Database/Migrations/tenant');
    }
}

Make sure tenancy()->check() is a helper to detect whether the current context is a tenant.

Tips:

Avoid modifying migration files directly. You can manage which migrations are loaded based on their paths and registration logic.
Always test locally before applying to production.