Manual · Laravel Module Maker

El generador del patrón

Escribe el módulo entero —modelo, repositorio, servicio, controlador, validación, migración, seeders, rutas con el permiso de cada una, pantallas y pruebas— con un solo comando, y con la misma forma en una aplicación única y en multiinquilino.

Un módulo agrupa varias subfuncionalidades y cada una es autocontenida: Modules/<Módulo>/<SubFuncionalidad>/<Capa>/<Contexto>/. La capa va dentro de la subfuncionalidad y el contexto es la hoja, así que leer, mover o borrar una funcionalidad es leer, mover o borrar una carpeta.

Por dónde empezar

Instalación

Composer y el primer comando.

Modificaciones manuales

Lo que el generador no escribe por su cuenta.

innodite:doctor

Empieza por aquí para diagnosticar el proyecto.

innodite:make-module

El generador principal, comando por comando.

Instalación, en dos líneas

bash

composer require innodite/laravel-module-maker:^5.1
php artisan innodite:module-setup

Y cuando algo no salga como esperabas, php artisan innodite:doctor: diagnostica en cascada y cada fallo trae la línea que lo arregla.

Manual · Laravel Module Maker

Instalación

bash

composer require innodite/laravel-module-maker:^5.1

Instala el paquete vía Composer. El siguiente paso es innodite:module-setup, que elige el modo del proyecto y deja escrita la configuración — ver su ficha en Los comandos.

Después de configurar el proyecto, innodite:doctor confirma que quedó bien:

bash

php artisan innodite:doctor

Antes de generar el primer módulo, revisar Modificaciones manuales: hay piezas que el generador no escribe por su cuenta.

Manual · Laravel Module Maker

Modificaciones manuales

Lo que el generador no escribe por su cuenta, y hay que dejar en el proyecto antes de generar el primer módulo.

1 · Namespace `Modules\` en el autoload

En composer.json del proyecto:

json

{
  "autoload": {
    "psr-4": {
      "App\\": "app/",
      "Modules\\": "Modules/"
    }
  }
}

bash

composer dump-autoload

2 · Middleware `InnoditeContextBridge`

Solo obligatorio en multitenant — en single-app, innodite:doctor no lo exige (no hay eje de contexto que resolver).

En bootstrap/app.php (Laravel 11+):

php

->withMiddleware(function (Middleware $middleware) {
    $middleware->appendToGroup('web', [
        \Innodite\LaravelModuleMaker\Middleware\InnoditeContextBridge::class,
    ]);
})

Inyecta, vía Inertia::share(), en cada request:

Prop	Contenido
`auth.context.route_prefix`	`central`, `tenant` — `null` en `single-app`
`auth.context.permission_prefix`	`central`, `tenant` — `null` en `single-app`
`auth.permissions`	Array de strings con los permisos del usuario autenticado

3 · Resolución de permisos del usuario

El middleware resuelve los permisos del usuario en este orden, y usa el primero que encuentre:

#	Cómo	Requiere
1	`$user->getAllPermissions()->pluck('name')`	`spatie/laravel-permission`, con `HasRoles` en el modelo `User`
2	`$user->getInnoditePermissions()`	El modelo `User` implementa `Innodite\LaravelModuleMaker\Contracts\InnoditeUserPermissions`
3	`[]` + warning en log	Ninguna de las dos anteriores

Implementación de la interfaz, si no se usa Spatie:

php

use Innodite\LaravelModuleMaker\Contracts\InnoditeUserPermissions;

class User extends Authenticatable implements InnoditeUserPermissions
{
    public function getInnoditePermissions(): array
    {
        return $this->permissions->pluck('name')->toArray();
    }
}

4 · Tablas de permisos y roles

El generador escribe el permiso de cada ruta y los seeders que los crean; las tablas son del proyecto. Con spatie/laravel-permission instalado y migrado, ya están.

5 · Ziggy, con `@routes` en el layout

Las pantallas generadas resuelven sus rutas por nombre (window.route('central.users.index')). Sin @routes en el layout Blade, window.route no existe y la pantalla no carga sus datos.

6 · `APP_KEY`

El grupo de middleware web cifra la sesión. Sin APP_KEY, la petición falla antes de llegar al middleware de permiso — el error no menciona el paquete ni el módulo.

Manual · Laravel Module Maker

innodite:doctor

bash

php artisan innodite:doctor {--continuar}

Diagnóstico en dos etapas. Corta en la primera que falla, salvo --continuar.

Etapa 1 · El entorno del generador — 8 comprobaciones, en este orden:

El modo del proyecto está configurado (contexts.json existe y es válido)
contexts.json declara los contextos que el modo exige (en single-app, ninguno; en multitenant, central y tenant), y cada uno tiene las 4 claves mínimas (id, class_prefix, folder, namespace_path)
Permisos de escritura en Modules/ y storage/logs/
Colisiones: directorios duplicados, ServiceProvider con namespace incorrecto o que no carga, migraciones duplicadas por contexto, comandos del proyecto que tapan a los del paquete
Estructura de pruebas retirada — cada módulo, buscando Tests/Feature/Shared/ o una pieza de contexto que incorpore un trait con use <Trait> en vez de llevar el código inline
config/make-module.php publicada
Stubs publicados en formato de una versión anterior (doble llave {{ }} sin ninguna triple {{{ }}})
Últimas 5 entradas del log de eventos (storage/logs/module_maker.log) — informativo, nunca hace fallar el diagnóstico

Etapa 2 · El contrato del proyecto anfitrión — 5 comprobaciones:

Modelo User — HasRoles (Spatie) o InnoditeUserPermissions
HandleInertiaRequests comparte auth.permissions
InnoditeContextBridge registrado en el grupo web — solo obligatorio en multitenant; en single-app se informa como no aplicable, nunca falla por esto
Ziggy instalado, con @routes en algún layout Blade
Si el proyecto declara frontend: innodite, que algún paquete instalado aporte esas plantillas

Parámetro	Efecto
`--continuar`	Ejecuta la Etapa 2 aunque la Etapa 1 haya fallado. El resultado final es éxito solo si ambas etapas pasan

Sin --continuar, un fallo en la Etapa 1 corta ahí mismo — la Etapa 2 no llega a ejecutarse.

Caso: primera verificación tras instalar el paquete.

bash

php artisan innodite:doctor

Si el modo no está configurado, imprime únicamente el fallo de la Etapa 1 y corta:

FALLA: no hay un modo configurado para este proyecto.
FIX: php artisan innodite:module-setup --mode=single-app|multitenant

Caso: el entorno está mal, y se quiere ver también el contrato del proyecto.

bash

php artisan innodite:doctor --continuar

Imprime el resultado de las 8 comprobaciones de la Etapa 1 (marcando cuáles fallan) y, a continuación, las 5 de la Etapa 2, sin detenerse en la primera.

Manual · Laravel Module Maker

innodite:module-setup

bash

php artisan innodite:module-setup {--mode=} {--tenancy=} {--frontend=} {--dry-run}

Configura el proyecto para poder generar. Sin modo elegido, ningún otro comando del paquete genera nada. Orden real de ejecución:

Resuelve el modo (--mode o pregunta interactiva) y lo persiste en .env como

MODULE_MAKER_MODE. Sin modo resuelto, el comando termina aquí.

Resuelve la tenencia — solo si el modo es multitenant; en single-app este paso se salta

por completo, sin preguntar nada. La persiste como MODULE_MAKER_TENANCY_PACKAGE.

Crea la carpeta de módulos (Modules/ por defecto).
Resuelve el frontend (--frontend o pregunta; default si no hay terminal). Nunca detiene el

comando, a diferencia del modo y la tenencia. La persiste como MODULE_MAKER_FRONTEND.

Crea module-maker-config/.
Publica config/make-module.php — solo si no existe ya, nunca sobrescribe.
Publica contexts.json — solo en multitenant, y solo si no existe ya.
Escribe los seeders de despliegue del proyecto y engancha el primero en DatabaseSeeder::run().

Parámetro	Valores	Efecto
`--mode=`	`single-app` \| `multitenant`	Obligatorio para poder generar. Sin valor válido y sin terminal interactiva, el comando falla
`--tenancy=`	`stancl` \| `none`	Solo se usa en `multitenant` — ignorado por completo en `single-app`. `stancl` envuelve las rutas del contexto `tenant` con los middleware de identificación por dominio; `none` deja el archivo con un aviso de qué envoltura falta, sin adivinarla
`--frontend=`	`default` \| `innodite`	Contra qué se generan las vistas. Un valor inválido no detiene la instalación: avisa y sigue con `default`
`--dry-run`	—	Ninguna escritura ocurre, tampoco en `.env`. Ver más abajo

Modules/                              (carpeta vacía)
module-maker-config/
config/make-module.php                (si no existía)
module-maker-config/contexts.json     (solo multitenant, si no existía)
database/seeders/*.php                (seeders de despliegue del proyecto)

Y modifica .env (tres líneas: MODULE_MAKER_MODE, MODULE_MAKER_TENANCY_PACKAGE en multitenant, MODULE_MAKER_FRONTEND) y database/seeders/DatabaseSeeder.php (agrega una llamada dentro de run()).

Los stubs NO se publican con este comando — solo innodite:publish-stubs los publica.

contexts.json no se publica — no hay eje de contexto que declarar. La tenencia no se pregunta.

--mode=single-app:

✔ Modo configurado: single-app
✔ Frontend: default
✔ config/make-module.php publicada
✔ Seeders de despliegue escritos
Configuración completa.

contexts.json se publica con dos contextos de fábrica:

json

{
    "contexts": {
        "central": {
            "id": "central", "is_tenant": false, "tenancy_strategy": "manual",
            "connection_key": "central", "class_prefix": "Central", "folder": "Central",
            "namespace_path": "Central", "route_file": "web.php",
            "route_prefix": "central", "route_name": "central.",
            "permission_prefix": "", "permission_middleware": "", "route_middleware": []
        },
        "tenant": {
            "id": "tenant", "is_tenant": true,
            "class_prefix": "Tenant", "folder": "Tenant", "namespace_path": "Tenant",
            "route_file": "tenant.php", "route_prefix": "tenant", "route_name": "tenant.",
            "permission_prefix": "", "permission_middleware": "", "route_middleware": []
        }
    }
}

El contexto tenant no declara connection_key ni tenancy_strategy — la conmuta el paquete de tenencia elegido.

--mode=multitenant --tenancy=stancl:

✔ Modo configurado: multitenant
✔ Tenencia: stancl
✔ Frontend: default
✔ contexts.json publicado con central y tenant
✔ Seeders de despliegue escritos
Configuración completa.

Con --tenancy=none, el archivo de rutas del contexto tenant queda con un aviso en vez de la envoltura de middleware:

// ⛔ FALTA LA ENVOLTURA DE TENENCIA — este proyecto declaró --tenancy=none.
// Aquí va el middleware que identifica al inquilino antes de resolver estas rutas.

Caso: proyecto nuevo, una sola aplicación.

bash

php artisan innodite:module-setup --mode=single-app

Caso: multiinquilino con stancl/tenancy ya instalado.

bash

php artisan innodite:module-setup --mode=multitenant --tenancy=stancl

Caso: multiinquilino con un paquete de tenencia que el generador no soporta.

bash

php artisan innodite:module-setup --mode=multitenant --tenancy=none

Caso: ver qué haría, sin tocar nada.

bash

php artisan innodite:module-setup --mode=multitenant --tenancy=stancl --dry-run

ENSAYO (--dry-run): no se va a escribir ni a ejecutar nada.
(ensayo) crearía Modules/
(ensayo) escribiría MODULE_MAKER_MODE=multitenant en .env
(ensayo) escribiría MODULE_MAKER_TENANCY_PACKAGE=stancl en .env
(ensayo) copiaría config/make-module.php
(ensayo) copiaría module-maker-config/contexts.json
Esto es lo que haría (5). No se escribió nada.

Manual · Laravel Module Maker

innodite:make-module

bash

php artisan innodite:make-module {name} {--context=} {--json} [-M] [-C] [-S] [-R] [-G] [-Q] {--dry-run}

Genera un módulo completo, o solo algunas de sus capas sobre uno que ya existe. El comando decide el modo por este orden de prioridad:

--json — gana sobre cualquier otro flag. Lee la configuración de un archivo.
Algún flag suelto (-M -C -S -R -G -Q) — genera solo esas capas.
Sin flags y el módulo no existe — genera el módulo completo.
Sin flags y el módulo ya existe — el comando se niega y sugiere add-entity o pasar flags

sueltos. Nunca sobrescribe un módulo completo por accidente.

Con flags sueltos combinados, hay una regla no evidente: si las seis están activas a la vez (sea porque se pasaron las seis explícitas, o porque no se pasó ninguna en add-entity), se agrega además un paso de cierre que genera tests, factory, vistas, rutas y el ServiceProvider. Con un subconjunto (por ejemplo, solo -M -Q), se generan exclusivamente esas capas — sin rutas, sin vistas, sin tests.

-G (migración) nunca genera solo la migración: las seis piezas de seeder (MigrationsList, InlineAlters, StageSeeder, ProductionSeeder, PermissionsSeeder, Data) van siempre juntas, más el registro del módulo en el orden de despliegue.

Parámetro	Descripción
`name`	Nombre del módulo, PascalCase (ej. `Invoice`). Rechaza nombres que no sean PascalCase y palabras reservadas de PHP/Laravel
`--context=`	`central` \| `tenant` \| el que declare el proyecto. Obligatorio en `multitenant`; no se pasa en `single-app`
`--json`	Lee `module-maker-config/{módulo}.json` en vez de generar por flags. No genera vistas Vue
`-M` / `--model`	Solo el modelo
`-C` / `--controller`	Solo el controlador
`-S` / `--service`	Solo el servicio + su interfaz
`-R` / `--repository`	Solo el repositorio + su interfaz
`-G` / `--migration`	La migración + las seis piezas de seeder juntas (nunca solo la migración)
`-Q` / `--request`	Solo los form requests (alta y edición)
`--dry-run`	Registra qué escribiría, sin escribir nada. La validación de cada archivo (placeholders resueltos, PHP válido, namespace correcto) se ejecuta igual

Sin ningún flag de componente y con el módulo ya existente, ver punto 4 de arriba.

Orden real de resolución, de más específico a más genérico:

#	Ruta	Gana
1	`module-maker-config/stubs/contextual/{Contexto}/`	El proyecto, para ese contexto
2	`module-maker-config/stubs/contextual/`	El proyecto
3	`vendor///stubs/module-maker/contextual/`	Un paquete instalado (empate: gana el primero por orden alfabético)
4	`stubs/contextual/` del propio paquete	Fuente de última instancia

Cada placeholder se escribe con triple llave ({{{ modelName }}}); antes de escribir, el comando rechaza el archivo si queda algún placeholder sin resolver, si el PHP no parsea, o si el namespace declarado no coincide con la ruta destino.

provider-boot.stub es opcional: si ningún nivel lo aporta, el boot() del ServiceProvider sale vacío — es el punto de enganche al menú de la aplicación, y el paquete no lo trae de fábrica.

php artisan innodite:make-module Invoice genera, bajo Modules/Invoice/:

Docs/history.md
Docs/architecture.md
Docs/schema.md
Providers/InvoiceServiceProvider.php
Routes/web.php
Database/Seeders/Application/InvoiceApplicationStageSeeder.php
Database/Seeders/Application/InvoiceApplicationProductionSeeder.php
Database/Seeders/Application/InvoiceApplicationPermissionsSeeder.php

Invoice/Models/Invoice.php
Invoice/Http/Controllers/InvoiceController.php
Invoice/Http/Requests/InvoiceStoreRequest.php
Invoice/Http/Requests/InvoiceUpdateRequest.php
Invoice/Services/InvoiceService.php
Invoice/Services/Contracts/InvoiceServiceInterface.php
Invoice/Repositories/InvoiceRepository.php
Invoice/Repositories/Contracts/InvoiceRepositoryInterface.php
Invoice/Database/Migrations/{timestamp}_create_invoices_table_final.php
Invoice/Database/Seeders/InvoiceInvoiceMigrationsList.php
Invoice/Database/Seeders/InvoiceInvoiceInlineAlters.php
Invoice/Database/Seeders/InvoiceInvoiceStageSeeder.php
Invoice/Database/Seeders/InvoiceInvoiceProductionSeeder.php
Invoice/Database/Seeders/InvoiceInvoicePermissionsSeeder.php
Invoice/Database/Seeders/InvoiceInvoiceData.php
Invoice/Database/Factories/InvoiceFactory.php
Invoice/Tests/Feature/InvoiceContract.php
Invoice/Tests/Feature/InvoiceTestCase.php
Invoice/Tests/Feature/InvoiceScaffoldTest.php
Invoice/Tests/Feature/InvoiceSchemaTest.php
Invoice/Tests/Feature/InvoicePermissionsTest.php
Invoice/Tests/Feature/InvoiceDeploymentTest.php
Invoice/Tests/Feature/InvoiceHttpTest.php
Invoice/resources/js/__tests__/InvoiceContract.js
Invoice/resources/js/__tests__/InvoiceIndex.test.js
Invoice/resources/js/Pages/InvoiceIndex.vue
Invoice/resources/js/Pages/InvoiceCreate.vue
Invoice/resources/js/Pages/InvoiceEdit.vue
Invoice/resources/js/Pages/InvoiceShow.vue
Invoice/Jobs/.gitkeep
Invoice/Notifications/.gitkeep
Invoice/Console/Commands/.gitkeep
Invoice/Exceptions/.gitkeep

29 archivos. Además, config/make-module.php recibe la línea 'Invoice/Invoice', dentro del array deploy.

⚠️ La primera subfuncionalidad de un módulo se llama igual que el módulo. Por eso los nombres de las piezas de seeder salen con el nombre repetido (InvoiceInvoiceStageSeeder.php) — no es un error, es la convención real de nombrado ({Módulo}{Subfuncionalidad}, y aquí ambos son Invoice). El modelo, el controlador, el servicio, el repositorio, los form requests, la factory y las vistas no duplican el nombre.

Mismo árbol, con Central/ (o Tenant/) insertado como hoja de cada capa y el prefijo de clase correspondiente. --context=central:

Docs/history.md · architecture.md · schema.md          (sin contexto, igual en los dos modos)
Providers/Central/CentralInvoiceServiceProvider.php
Routes/web.php
Database/Seeders/Application/Central/CentralInvoiceApplicationStageSeeder.php
Database/Seeders/Application/Central/CentralInvoiceApplicationProductionSeeder.php
Database/Seeders/Application/Central/CentralInvoiceApplicationPermissionsSeeder.php

Invoice/Models/Central/CentralInvoice.php
Invoice/Http/Controllers/Central/CentralInvoiceController.php
Invoice/Http/Requests/Central/CentralInvoiceStoreRequest.php
Invoice/Http/Requests/Central/CentralInvoiceUpdateRequest.php
Invoice/Services/Central/CentralInvoiceService.php
Invoice/Services/Contracts/Central/CentralInvoiceServiceInterface.php
Invoice/Repositories/Central/CentralInvoiceRepository.php
Invoice/Repositories/Contracts/Central/CentralInvoiceRepositoryInterface.php
Invoice/Database/Migrations/Central/{timestamp}_create_invoices_table_final.php
Invoice/Database/Seeders/Central/CentralInvoiceInvoiceMigrationsList.php
Invoice/Database/Seeders/Central/CentralInvoiceInvoiceInlineAlters.php
Invoice/Database/Seeders/Central/CentralInvoiceInvoiceStageSeeder.php
Invoice/Database/Seeders/Central/CentralInvoiceInvoiceProductionSeeder.php
Invoice/Database/Seeders/Central/CentralInvoiceInvoicePermissionsSeeder.php
Invoice/Database/Seeders/Central/CentralInvoiceInvoiceData.php
Invoice/Database/Factories/Central/CentralInvoiceFactory.php
Invoice/Tests/Feature/Central/CentralInvoiceContract.php
Invoice/Tests/Feature/Central/CentralInvoiceTestCase.php
Invoice/Tests/Feature/Central/CentralInvoiceScaffoldTest.php
Invoice/Tests/Feature/Central/CentralInvoiceSchemaTest.php
Invoice/Tests/Feature/Central/CentralInvoicePermissionsTest.php
Invoice/Tests/Feature/Central/CentralInvoiceDeploymentTest.php
Invoice/Tests/Feature/Central/CentralInvoiceHttpTest.php
Invoice/resources/js/__tests__/Central/CentralInvoiceContract.js
Invoice/resources/js/__tests__/Central/CentralInvoiceIndex.test.js
Invoice/resources/js/Pages/Central/CentralInvoiceIndex.vue
Invoice/resources/js/Pages/Central/CentralInvoiceCreate.vue
Invoice/resources/js/Pages/Central/CentralInvoiceEdit.vue
Invoice/resources/js/Pages/Central/CentralInvoiceShow.vue
Invoice/Jobs/Central/.gitkeep
Invoice/Notifications/Central/.gitkeep
Invoice/Console/Commands/Central/.gitkeep
Invoice/Exceptions/Central/.gitkeep

El modelo lleva protected $connection = 'central';. config/make-module.php recibe 'Invoice/Central/Invoice', dentro de deploy['central'].

Con --context=tenant, no es solo cambiar el prefijo. Además:

Las rutas van a Routes/tenant.php, no web.php.
La envoltura de middleware es la del paquete de tenencia (identificación por dominio), en vez del

recorrido de dominios centrales.

El modelo no declara $connection — la conmuta el paquete de tenencia; sin uno configurado,

el modelo lleva una nota explicando quién debe conmutarla.

El prefijo de permiso y middleware son tenant/tenant-permission, no central/central-permission.

Fuera de eso, la estructura es idéntica: mismas 29 piezas.

Caso: primer módulo del proyecto, contexto central.

bash

php artisan innodite:make-module Invoice --context=central

✔ Generado Modules/Invoice/ (29 archivos)
✔ Registrado en el orden de despliegue: Invoice/Central/Invoice

Caso: aplicación de un solo tenant.

bash

php artisan innodite:make-module Invoice

Caso: al módulo Invoice ya generado le falta el repositorio y la migración.

bash

php artisan innodite:make-module Invoice --context=central -R -G

✔ Repositorio + interfaz generados
✔ Migración + seis piezas de seeder generadas
✔ Registrado en el orden de despliegue

No genera rutas, vistas ni tests — solo lo pedido.

Caso: ver qué escribiría, antes de generar de verdad.

bash

php artisan innodite:make-module Invoice --context=central --dry-run

ENSAYO (--dry-run): no se va a escribir ni a ejecutar nada.
(ensayo) escribiría Modules/Invoice/Models/Central/CentralInvoice.php
(ensayo) escribiría Modules/Invoice/Http/Controllers/Central/CentralInvoiceController.php
… (29 líneas)
Esto es lo que haría (29). No se escribió nada.

Manual · Laravel Module Maker

innodite:add-entity

bash

php artisan innodite:add-entity {module} {entity} {--context=} [-M] [-C] [-S] [-R] [-G] [-Q] {--dry-run}

Agrega una entidad nueva a un módulo ya existente. Exige que el módulo exista; si no, sugiere make-module.

Sin ningún flag, se activan los seis (a diferencia de make-module, donde ausencia de flags dispara un camino de código distinto para el módulo completo). Con las seis activas se genera también el paso de cierre: rutas, vistas, tests, factory, y se actualiza el ServiceProvider del módulo (no se recrea — se le inyecta el use y el bind nuevos en sus marcadores).

Los 3 seeders maestros del módulo (Application*Seeder), si ya existen, se saltan.

Parámetro	Descripción
`module`	Nombre del módulo existente (ej. `UserManagement`)
`entity`	Nombre de la entidad nueva, PascalCase (ej. `Role`)
`--context=`	`central` \| `tenant` \| el que declare el proyecto. Obligatorio en `multitenant`
`-M` a `-Q`	Mismos flags que `make-module`. Sin ninguno, equivale a las seis activas
`--dry-run`	Registra qué escribiría, sin escribir nada

La ruta y el permiso de la entidad nueva salen de la entidad, no del módulo — por eso Role no hereda rutas ni permisos de UserManagement.

php artisan innodite:add-entity UserManagement Role genera, bajo Modules/UserManagement/Role/:

Role/Models/Role.php
Role/Http/Controllers/RoleController.php
Role/Http/Requests/RoleStoreRequest.php
Role/Http/Requests/RoleUpdateRequest.php
Role/Services/RoleService.php
Role/Services/Contracts/RoleServiceInterface.php
Role/Repositories/RoleRepository.php
Role/Repositories/Contracts/RoleRepositoryInterface.php
Role/Database/Migrations/{timestamp}_create_roles_table_final.php
Role/Database/Seeders/UserManagementRoleMigrationsList.php
Role/Database/Seeders/UserManagementRoleInlineAlters.php
Role/Database/Seeders/UserManagementRoleStageSeeder.php
Role/Database/Seeders/UserManagementRoleProductionSeeder.php
Role/Database/Seeders/UserManagementRolePermissionsSeeder.php
Role/Database/Seeders/UserManagementRoleData.php
Role/Database/Factories/RoleFactory.php
Role/Tests/Feature/RoleContract.php
Role/Tests/Feature/RoleTestCase.php
Role/Tests/Feature/RoleScaffoldTest.php
Role/Tests/Feature/RoleSchemaTest.php
Role/Tests/Feature/RolePermissionsTest.php
Role/Tests/Feature/RoleDeploymentTest.php
Role/Tests/Feature/RoleHttpTest.php
Role/resources/js/__tests__/RoleContract.js
Role/resources/js/__tests__/RoleIndex.test.js
Role/resources/js/Pages/RoleIndex.vue
Role/resources/js/Pages/RoleCreate.vue
Role/resources/js/Pages/RoleEdit.vue
Role/resources/js/Pages/RoleShow.vue
Role/Jobs/.gitkeep
Role/Notifications/.gitkeep
Role/Console/Commands/.gitkeep
Role/Exceptions/.gitkeep

Aquí Role ≠ UserManagement, así que los nombres de seeder no se duplican (UserManagementRoleStageSeeder.php, no UserManagementUserManagementStageSeeder.php).

Modificados, no nuevos: Modules/UserManagement/Routes/web.php (nueva sección de rutas antes del marcador) y config/make-module.php (línea 'UserManagement/Role', en deploy). Omitidos porque ya existían: Providers/UserManagementServiceProvider.php (se actualiza, no se recrea) y los 3 seeders maestros.

--context=central:

Role/Models/Central/CentralRole.php
Role/Http/Controllers/Central/CentralRoleController.php
Role/Http/Requests/Central/CentralRoleStoreRequest.php
Role/Http/Requests/Central/CentralRoleUpdateRequest.php
Role/Services/Central/CentralRoleService.php
Role/Services/Contracts/Central/CentralRoleServiceInterface.php
Role/Repositories/Central/CentralRoleRepository.php
Role/Repositories/Contracts/Central/CentralRoleRepositoryInterface.php
Role/Database/Migrations/Central/{timestamp}_create_roles_table_final.php
Role/Database/Seeders/Central/CentralUserManagementRoleMigrationsList.php
Role/Database/Seeders/Central/CentralUserManagementRoleInlineAlters.php
Role/Database/Seeders/Central/CentralUserManagementRoleStageSeeder.php
Role/Database/Seeders/Central/CentralUserManagementRoleProductionSeeder.php
Role/Database/Seeders/Central/CentralUserManagementRolePermissionsSeeder.php
Role/Database/Seeders/Central/CentralUserManagementRoleData.php
Role/Database/Factories/Central/CentralRoleFactory.php
Role/Tests/Feature/Central/CentralRoleContract.php
Role/Tests/Feature/Central/CentralRoleTestCase.php
Role/Tests/Feature/Central/CentralRoleScaffoldTest.php
Role/Tests/Feature/Central/CentralRoleSchemaTest.php
Role/Tests/Feature/Central/CentralRolePermissionsTest.php
Role/Tests/Feature/Central/CentralRoleDeploymentTest.php
Role/Tests/Feature/Central/CentralRoleHttpTest.php
Role/resources/js/__tests__/Central/CentralRoleContract.js
Role/resources/js/__tests__/Central/CentralRoleIndex.test.js
Role/resources/js/Pages/Central/CentralRoleIndex.vue
Role/resources/js/Pages/Central/CentralRoleCreate.vue
Role/resources/js/Pages/Central/CentralRoleEdit.vue
Role/resources/js/Pages/Central/CentralRoleShow.vue
Role/Jobs/Central/.gitkeep
Role/Notifications/Central/.gitkeep
Role/Console/Commands/Central/.gitkeep
Role/Exceptions/Central/.gitkeep

Modificados: Routes/web.php + Providers/Central/CentralUserManagementServiceProvider.php (inyección) + config/make-module.php → deploy['central'] recibe 'UserManagement/Central/Role',.

Con --context=tenant: mismo listado sustituyendo Central → Tenant, escribiendo en Routes/tenant.php, con las mismas diferencias de fondo que en make-module (envoltura de middleware, sin $connection en el modelo, prefijo de permiso).

Caso: el módulo UserManagement ya existe con la entidad User; se agrega Role.

bash

php artisan innodite:add-entity UserManagement Role --context=central

✔ Generado Modules/UserManagement/Role/ (29 archivos)
✔ Modules/UserManagement/Routes/web.php actualizado
✔ Providers/Central/CentralUserManagementServiceProvider.php actualizado
✔ Registrado en el orden de despliegue: UserManagement/Central/Role

Caso: la misma entidad, en el contexto del inquilino.

bash

php artisan innodite:add-entity UserManagement Role --context=tenant

Caso: solo hace falta el modelo, el controlador y el servicio de la entidad nueva.

bash

php artisan innodite:add-entity UserManagement Permission --context=central -M -C -S

No genera rutas, vistas ni tests — solo esas tres capas.

Manual · Laravel Module Maker

innodite:deploy

bash

php artisan innodite:deploy {environment} {--context=} {--module=} {--tenant=} {--all} {--force} {--dry-run}

Ejecuta los seeders del proyecto en el orden declarado en config('make-module.deploy'): esquema, datos canónicos, permisos, y el usuario administrador al cerrar. El orden es un array asociativo contexto → lista de rutas Módulo/Contexto/Subfuncionalidad (o una lista plana en single-app).

Antes de desplegar, comprueba que existan cache/jobs si el proyecto las usa como driver de caché o colas (pide php artisan migrate primero si faltan).

Parámetro	Valores	Efecto
`environment`	`stage` \| `production`	Obligatorio. En el código, ambos ejecutan exactamente el mismo camino — la diferencia real vive en los seeders generados, no en este comando (ver abajo)
`--context=`	`central` \| `tenant` \| el que declare el proyecto	Obligatorio en `multitenant`; prohibido en `single-app` — si se pasa, falla
`--module=`	nombre del módulo	Despliega solo las subfuncionalidades de ese módulo (filtra por módulo y, si se pasó, por contexto)
`--tenant=`	id del inquilino	Con `--context=tenant`: despliega solo ese inquilino
`--all`	—	Con `--context=tenant`: despliega todos, uno tras otro
`--force`	—	Omite la confirmación aunque `SEEDER_DESTRUCTIVE` esté activo
`--dry-run`	—	No ejecuta ningún seeder — registra qué haría y contra qué conexión

Combinaciones que fallan:

single-app + --context=: "el modo no tiene contextos: no pases --context=…"
multitenant sin --context=: "falta --context: aquí hay dos despliegues, contra dos bases distintas"
--context=tenant sin --tenant= ni --all: "falta elegir el tenant: aquí hay una base por cliente"
--tenant= y --all juntos: "--tenant y --all piden cosas distintas"
--module= de un módulo sin ninguna subfuncionalidad en el contexto pedido: falla nombrando

módulo y contexto

bash

php artisan innodite:deploy stage --context=central
php artisan innodite:deploy stage --context=tenant --tenant=acme
php artisan innodite:deploy stage --context=tenant --all

deploy es un array con una clave por contexto (central, tenant), cada una con su propia lista de rutas. En consola no hay middleware que identifique el tenant por dominio — por eso --context=tenant exige decir explícitamente cuál (--tenant=) o todos (--all).

Caso: aplicación única, ambiente de stage.

bash

php artisan innodite:deploy stage

Caso: multiinquilino, la aplicación central.

bash

php artisan innodite:deploy stage --context=central

Caso: multiinquilino, un solo cliente.

bash

php artisan innodite:deploy stage --context=tenant --tenant=acme

Caso: multiinquilino, todos los clientes de una vez.

bash

php artisan innodite:deploy stage --context=tenant --all

Caso: solo un módulo, sin levantar el resto del proyecto.

bash

php artisan innodite:deploy stage --module=Invoice --context=central

Caso: antes de tocar producción, ver qué haría.

bash

php artisan innodite:deploy production --context=central --dry-run

ENSAYO (--dry-run): no se va a escribir ni a ejecutar nada.
(ensayo) ejecutaría CentralInvoiceApplicationProductionSeeder contra la conexión 'central'
(ensayo) ejecutaría CentralUserManagementApplicationProductionSeeder contra la conexión 'central'
Esto es lo que haría (2). No se tocó la base de datos.

Manual · Laravel Module Maker

innodite:migrate-one

bash

php artisan innodite:migrate-one {coordinate} {--context=} {--force} {--dry-run}

Ejecuta una sola migración, nombrada por su coordenada Modulo:Contexto/archivo.php.

Parseo de la coordenada: se corta en los dos puntos (módulo / resto); dentro del resto, en la última barra (/) — todo lo anterior es la carpeta de contexto, lo posterior es el archivo. El módulo se normaliza a PascalCase. Con eso arma la ruta Modules/{Módulo}/Database/Migrations/{Contexto}/{archivo} y comprueba que exista.

El contexto de ejecución (contra qué base corre) se deriva de la coordenada, salvo que se pase --context=, que lo fuerza.

Parámetro	Descripción
`coordinate`	`Modulo:Contexto/archivo.php` — ej. `Invoice:Central/2026_08_01_120000_crea_facturas.php`
`--context=`	Fuerza el contexto de ejecución en vez de derivarlo de la coordenada
`--force`	Omite la confirmación interactiva. Sin consola interactiva y sin `--force`, el comando falla en vez de preguntar
`--dry-run`	Imprime el resumen (migración, módulo, contexto, conexión, base) y termina — no llega a comprobar siquiera que la base exista

Caso: aplicar una migración puntual que quedó pendiente.

bash

php artisan innodite:migrate-one "Invoice:Central/2026_08_01_120000_crea_facturas.php"

Migración: 2026_08_01_120000_crea_facturas.php
Módulo: Invoice · Contexto: Central · Conexión: central · Base: laravel
¿Continuar? (yes/no) [no]:

Caso: lo mismo, sin pedir confirmación (para un script).

bash

php artisan innodite:migrate-one "Invoice:Central/2026_08_01_120000_crea_facturas.php" --force

Caso: ver qué haría, sin tocar la base ni comprobar que exista.

bash

php artisan innodite:migrate-one "Invoice:Central/2026_08_01_120000_crea_facturas.php" --dry-run

Migración: 2026_08_01_120000_crea_facturas.php
Módulo: Invoice · Contexto: Central · Conexión: central · Base: laravel
Dry-run completado. No se aplicó nada.

Manual · Laravel Module Maker

innodite:crear-bd-test

bash

php artisan innodite:crear-bd-test {--connection=} {--force} {--dry-run}

Copia el esquema de una conexión real a su base de pruebas — sin copiar ni una fila. Soporta MySQL, MariaDB y SQLite; cualquier otro driver hace fallar el comando.

--connection= es la conexión de origen; sin ella, usa config('database.default'). El destino se calcula solo: en MySQL/MariaDB, se le agrega el sufijo _test si no lo tiene ya; en SQLite, se agrega _test antes de la extensión del archivo (app.sqlite → app_test.sqlite). Si la conexión apunta a :memory:, falla — no se puede clonar.

Dos guardas antes de tocar nada: el nombre destino tiene que terminar en _test (es lo único que impide borrar la base real por accidente), y si la conexión de origen ya apunta a una base _test, el comando se niega.

Parámetro	Efecto
`--connection=`	Conexión de la que se clona el esquema. Sin ella, la conexión por defecto de la aplicación
`--force`	Sin destino previo, clona igual. Con destino ya existente: sin `--force` no toca nada («ya existe, no se toca»); con `--force`, lo rehace desde cero (`DROP DATABASE`/borra el archivo, y recrea)
`--dry-run`	Enumera las tablas que copiaría, sin tocar nada. También responde al ensayo activado por otro comando (p. ej. `innodite:test` invocándolo internamente)

No existen --context= ni --reclonar en este comando — son parámetros de innodite:test.

Caso: primera vez, sobre la conexión por defecto.

bash

php artisan innodite:crear-bd-test

Clonando esquema de 'laravel' a 'laravel_test'…
✔ 14 tablas copiadas

Caso: una conexión de multiinquilino en particular.

bash

php artisan innodite:crear-bd-test --connection=tenant_one

Caso: la base _test ya existe y se sabe que quedó con un esquema viejo.

bash

php artisan innodite:crear-bd-test --force

La base laravel_test existe: se rehace desde cero.
✔ 14 tablas copiadas

Caso: ver qué tablas copiaría, sin tocar nada.

bash

php artisan innodite:crear-bd-test --connection=mysql --dry-run

ENSAYO (--dry-run): no se va a escribir ni a ejecutar nada.
(ensayo) copiaría users
(ensayo) copiaría permissions
… (14 líneas)
Esto es lo que haría (14). No se tocó ninguna base de datos.

Manual · Laravel Module Maker

innodite:test

bash

php artisan innodite:test {module} {subfeature} {--context=} {--filter=} {--continuar} {--reclonar} {--sin-reclonar} {--repetir=1}

Ejecuta el contrato de pruebas de una subfuncionalidad — no de un módulo completo. Corre en cascada, en este orden exacto, y corta en la primera que falla salvo --continuar:

Orden	Clase	Cubre
1	`ScaffoldTest`	El andamiaje existe y su contenido cumple
2	`SchemaTest`	Tablas y columnas
3	`PermissionsTest`	Permiso único por ruta, sembrado, y la puerta
4	`DeploymentTest`	El despliegue, ejecutado de verdad
5	`HttpTest`	El comportamiento del negocio

El tema 6 (la vista) nunca lo corre este comando — lo ejecuta Vitest, aparte. El comando lo nombra siempre al terminar, pase lo que pase, para que nadie lo dé por corrido en silencio.

Antes de ejecutar, comprueba: que el grupo esté completo (manifiesto + base + las cinco piezas — sin eso ninguna puede derivar rutas ni permisos), y que no tenga la estructura de pruebas retirada desde v5.0.0 (Tests/Feature/Shared/, o un trait incorporado con use <Trait> en vez de inline — en aplicación única esta comprobación se salta, porque no puede existir un trait compartido entre contextos que no existen). Si encuentra cualquiera de las dos cosas, no ejecuta nada.

Parámetro	Efecto
`module`	Nombre del módulo (ej. `Invoice`)
`subfeature`	Subfuncionalidad dentro del módulo (ej. `Payment`)
`--context=`	En `multitenant`: contexto sobre el que corre el grupo
`--filter=`	Patrón de PHPUnit — acota qué test, dentro de cada pieza, se ejecuta
`--continuar`	No corta en la primera pieza que falla — acumula y reporta todas al final
`--reclonar`	Reconstruye la base `_test` antes de empezar, sin mirar en qué estado está
`--sin-reclonar`	En la clasificación de un rojo, no reclona — para investigar el fallo tal cual
`--repetir=N`	(default `1`) Repite la pieza fallida N veces, en la clasificación, para distinguir intermitente de defecto

bash

php artisan innodite:test Invoice Payment --context=central

Las clases llevan el prefijo del contexto (CentralInvoicePayment...). La ruta del grupo es Modules/{Modulo}/{SubFuncion}/Tests/Feature/{Contexto}.

Caso: correr el contrato completo de una subfuncionalidad.

bash

php artisan innodite:test Invoice Payment --context=central

Scaffold ✔  Schema ✔  Permissions ✔  Deployment ✔  Http ✔
Tema 6 (vista): no ejecutado aquí — correr Vitest en resources/js/__tests__/Central/Payment/
Contrato completo: 5/5 piezas en verde.

Caso: acotar a una sola prueba dentro del grupo.

bash

php artisan innodite:test Invoice Payment --filter=test_no_se_ve_sin_permiso

Caso: ver el grupo entero de una pasada, sin corte temprano.

bash

php artisan innodite:test Invoice Payment --continuar

Scaffold ✔  Schema ✔  Permissions ✘  Deployment ✘  Http ✘
3 de 5 piezas fallaron. Detalle de cada una arriba.

Caso: un rojo que podría deberse a una base _test desactualizada.

bash

php artisan innodite:test Invoice Payment --reclonar

Caso: confirmar si un rojo es intermitente antes de investigarlo como defecto.

bash

php artisan innodite:test Invoice Payment --sin-reclonar --repetir=3

Permissions ✘ (intento 1) ✔ (intento 2) ✔ (intento 3)
Clasificado como INTERMITENTE — no es base sucia ni defecto confirmado.

Manual · Laravel Module Maker

innodite:publish-stubs

bash

php artisan innodite:publish-stubs [stub...] {--all} {--force}

Exporta al proyecto las plantillas (stubs) que se vayan a personalizar, desde stubs/contextual/ del paquete instalado hacia module-maker-config/stubs/contextual/ del proyecto.

Sin argumentos y sin --all: no copia nada — solo lista el catálogo completo del paquete, en

columnas, con la advertencia de que una plantilla exportada deja de actualizarse con el paquete.

Con nombres concretos (con o sin el sufijo .stub): copia solo esas. Si alguno de los

nombres pedidos no existe, el comando falla completo y no copia nada — es todo o nada.

Con --all: copia el catálogo entero, sin necesidad de nombrarlas.

Existe además la vía nativa de Laravel php artisan vendor:publish --tag=module-maker-stubs, que copia todas de golpe sin las advertencias ni el chequeo granular de este comando — son caminos distintos, no uno sustituye al otro.

Parámetro	Efecto
`stub...`	Nombres de los stubs a publicar. Sin argumentos: solo lista
`--all`	Exporta el catálogo completo
`--force`	Sobrescribe las que ya estén exportadas. Sin ella, una plantilla ya exportada se conserva tal cual, sin tocarla

Caso: ver qué plantillas existen, antes de decidir cuál personalizar.

bash

php artisan innodite:publish-stubs

34 plantillas disponibles:
controller.stub        service.stub            vue-index.stub
repository.stub         model.stub              vue-create.stub
… (en columnas)
Exportar deja de actualizarse con el paquete. Exporta solo lo que vayas a tocar.

Caso: personalizar solo la plantilla del controlador.

bash

php artisan innodite:publish-stubs controller

✔ Exportado controller.stub → module-maker-config/stubs/contextual/controller.stub

Caso: personalizar el controlador y el modelo.

bash

php artisan innodite:publish-stubs controller model

Caso: exportar todo el catálogo.

bash

php artisan innodite:publish-stubs --all

Caso: ya se exportó controller y se quiere reemplazarlo por la versión actual del paquete.

bash

php artisan innodite:publish-stubs controller --force

Manual · Laravel Module Maker

innodite:migrate-plan (retirado)

Retirado en la v4. Ejecutarlo siempre devuelve error (código de salida 1), nunca éxito — un comando que no ejecuta nada y termina en verde sería peor que no tenerlo.

Usar innodite:deploy — ver su ficha en Los comandos. Para una migración suelta, innodite:migrate-one.

bash

php artisan innodite:deploy stage --context=central
php artisan innodite:migrate-one "Invoice:Central/2026_08_01_120000_crea_facturas.php"

Ejemplo

bash

php artisan innodite:migrate-plan

FALLA: innodite:migrate-plan se retiró en la v4.
FIX: despliega con innodite:deploy.
     php artisan innodite:deploy stage --context=central
     Una migración suelta:
     php artisan innodite:migrate-one <Modulo:Contexto/archivo.php>

El comando acepta cualquier opción antigua (por ejemplo --context=) sin rechazarla por firma inválida — la ignora y muestra el mismo mensaje de retiro, en vez de un error de consola sobre una opción que ya no existe.

Por dónde empezar

Instalación

Modificaciones manuales

innodite:doctor

innodite:make-module

Instalación, en dos líneas

1 · Namespace Modules\ en el autoload

2 · Middleware InnoditeContextBridge

3 · Resolución de permisos del usuario

4 · Tablas de permisos y roles

5 · Ziggy, con @routes en el layout

6 · APP_KEY

Ejemplo

1 · Namespace `Modules\` en el autoload

2 · Middleware `InnoditeContextBridge`

5 · Ziggy, con `@routes` en el layout

6 · `APP_KEY`