Download the PHP package innodite/laravel-module-maker without Composer

🏗️ Innodite Laravel Module Maker

v3.5.3 — Generador de módulos Laravel con arquitectura de contextos dinámicos (Central, Shared, Tenant) para proyectos multi-tenant. Genera backend completo, inyecta rutas y crea vistas Vue 3 listas para usar — todo con un solo comando. Soporta múltiples entidades por módulo con subcarpeta aislada por entidad ({Tipo}/{Contexto}/{Entidad}/).

⚠️ Versiones Deprecadas

Se consideran deprecados los tags históricos con referencias heredadas a software/proyecto externo.

Tags deprecados:

• v2.5.0
• v3.2.7 a v3.4.0

Versión mínima recomendada para uso nuevo:

• v3.4.1+

Nota: la deprecación es de soporte/uso recomendado. No se reescribe el historial Git publicado.

📋 Tabla de Contenidos

• Requisitos
• Instalación
• Tabla comparativa de contextos
• Versiones Deprecadas
• Arquitectura Frontend
• Guía de comandos
• Archivos generados por contexto
• Flujo completo por contexto
• Composables Vue 3
• Stubs contextuales
• Bridge Frontend-Backend
• Estructura de contextos
• Estructura de árbol de un módulo generado
• Convenciones de nomenclatura
• Flujo de inyección de rutas
• Auditoría
• Pruebas
• Estándares de código
• Publicar en Packagist
• Changelog
• Licencia

Nuevos en v3.5.x:

• Subcarpeta por entidad — patrón {Tipo}/{Contexto}/{Entidad}/
• innodite:add-entity — nuevo comando para módulos multi-entidad

✅ Requisitos

Compatible opcionalmente con stancl/tenancy y spatie/laravel-permission.

🚀 Instalación

Al instalar por primera vez, el paquete detecta la ausencia de configuración y sugiere el setup en consola.

Inicializar el proyecto (requerido)

Crea module-maker-config/ en la raíz del proyecto con:

• contexts.json — Definición de contextos y tenants
• stubs/contextual/ — Plantillas PHP y Vue personalizables

Publicar assets manualmente

🗺️ Tabla comparativa de contextos

Los 4 contextos disponibles cubren todos los escenarios de un proyecto multi-tenant:

Descripción rápida de cada contexto:

• central → Panel administrativo global. Rutas en web.php. Prefijo Central.
• shared → Código híbrido accesible tanto desde el panel central como desde el panel tenant. Inyecta rutas en DOS archivos simultáneamente.
• tenant_shared → Estándar para todos los tenants. Sin prefijo de URL ni de nombre de ruta.
• tenant → Tenants específicos del proyecto (INNODITE, ACME, etc.). Un array en contexts.json, cada entrada genera su propio espacio aislado.

🖥️ Arquitectura Frontend

Regla fundamental — No negociable en este paquete.

Los controladores utilizan el trait RendersInertiaModule y el método renderModule() para devolver la vista Inertia correcta según el contexto. Nunca pasan datos de negocio por props de Inertia.

Las vistas Vue son shells que se autocargan al montarse vía axios. Inertia nunca transporta datos de negocio; solo gestiona la navegación SPA.

🛠️ Guía de comandos

innodite:make-module — Generador principal

Genera backend completo + vistas Vue en un solo comando.

Flags de componentes:

Validaciones de seguridad:

• Nombres no PascalCase son rechazados
• Palabras reservadas de PHP y Laravel bloqueadas: class, model, auth, route, etc.
• Módulos duplicados bloqueados con opción de añadir componentes
• En caso de error, se ofrece rollback para eliminar archivos generados

innodite:add-entity — Agregar entidad a módulo existente

Agrega una nueva entidad a un módulo ya existente, generando sus componentes dentro de la subcarpeta de entidad correspondiente. Diseñado para módulos multi-entidad como UserManagement (con User, Role, Permission, Module).

Firma:

Ejemplo de archivos generados — add-entity UserManagement Role --context=central:

Diferencia con make-module:

innodite:module-setup — Configuración inicial

Crea la estructura de configuración del paquete en la raíz del proyecto. Debe ejecutarse una sola vez al inicializar un nuevo proyecto que use este paquete.

innodite:module-check — Diagnóstico de entorno

Verifica el entorno del proyecto e informa sobre:

1. contexts.json — validez, estructura y claves requeridas
2. Permisos de escritura en Modules/, routes/, storage/logs/
3. Colisiones de nombres entre módulos y ServiceProviders
4. Últimas 5 entradas del log de auditoría

innodite:check-env — Contrato de Datos Frontend-Backend

Verifica el bridge Inertia y, si algo falta, imprime el bloque de código exacto a copiar:

1. Modelo User — HasRoles (Spatie) o InnoditeUserPermissions
2. HandleInertiaRequests — auth.permissions compartido
3. InnoditeContextBridge — registrado en el stack web

innodite:publish-frontend — Composables Vue 3

Publica en resources/js/Composables/:

• useModuleContext.js
• usePermissions.js

innodite:migrate-plan — Orquestador de Migraciones por Manifiesto

Ejecuta migraciones en el orden exacto definido en un manifiesto JSON. Es ideal cuando hay dependencias entre módulos y contextos. Antes de ejecutar, valida la conexión objetivo y verifica que la base de datos exista para evitar procesos parciales o lanzados contra una BD incorrecta.

Formato de coordenadas soportado:

• Migraciones: Modulo:Contexto/Archivo.php
• Seeders: Modulo:Contexto/ClaseSeeder

Ejemplo real de manifiesto (module-maker-config/migrations/tenant_innodite_order.json):

Cómo resuelve rutas internas:

• User:Shared/2026_...php → Modules/User/Database/Migrations/Shared/2026_...php
• Roles:Tenant/Shared/TenantSharedRoleSeeder → Modules\Roles\Database\Seeders\Tenant\Shared\TenantSharedRoleSeeder

Qué valida el comando:

• Que el manifiesto exista y sea JSON válido
• Que migrations y seeders sean arrays
• Que cada coordenada de migración apunte a un archivo real
• Que el formato de coordenada sea correcto

Mensajes de error claros:

Si una coordenada no existe, el comando responde con la ruta esperada para corregirla rápidamente. Si la base de datos objetivo no existe, corta el proceso antes de ejecutar migraciones o seeders.

innodite:migrate-one — Ejecutar una Migración Específica

Permite ejecutar una coordenada de migración puntual sin correr el manifiesto completo. Está pensado para casos quirúrgicos donde necesitas lanzar una sola migración y mantener sincronizado el manifiesto correspondiente.

Qué hace internamente:

1. Resuelve la ruta exacta del archivo de migración desde la coordenada.
2. Detecta automáticamente el manifiesto objetivo según el contexto.
3. Si la coordenada aplica a múltiples manifiestos, muestra los destinos y pide confirmación.
4. Muestra antes de ejecutar:
   • Tipo: migración
   • Coordenada
   • Conexión
   • Base de datos
   • Manifiesto destino
   • Ruta real del archivo
5. Si la coordenada no está registrada en el manifiesto, la agrega primero.
6. Ejecuta solo la migración indicada.

Reglas de resolución:

• Central => central_order.json
• Shared => puede aplicar a central_order.json y a los manifiestos tenant
• Tenant/Shared => aplica a todos los manifiestos tenant
• Tenant/X => aplica al manifiesto tenant_x_order.json correspondiente

Importante:

• Requiere confirmación interactiva antes de ejecutar, salvo que uses --yes.
• En --dry-run no modifica el manifiesto ni ejecuta nada.
• Si la base de datos objetivo no existe, falla antes de iniciar el proceso.

innodite:seed-one — Ejecutar un Seeder Específico

Permite ejecutar un seeder puntual sin correr el manifiesto completo. Está pensado para casos quirúrgicos donde necesitas lanzar un solo seeder y mantener sincronizado el manifiesto correspondiente.

Qué hace internamente:

1. Resuelve el FQCN (clase completa) del seeder desde la coordenada.
2. Detecta automáticamente el manifiesto objetivo según el contexto.
3. Si la coordenada aplica a múltiples manifiestos, muestra los destinos y pide confirmación.
4. Muestra antes de ejecutar:
   • Tipo: seeder
   • Coordenada
   • Conexión
   • Base de datos
   • Manifiesto destino
   • Clase real que va a ejecutar
5. Si la coordenada no está registrada en el manifiesto, la agrega primero.
6. Ejecuta solo el seeder indicado.

Reglas de resolución:

• Central => central_order.json
• Shared => puede aplicar a central_order.json y a los manifiestos tenant
• Tenant/Shared => aplica a todos los manifiestos tenant
• Tenant/X => aplica al manifiesto tenant_x_order.json correspondiente

Importante:

• Requiere confirmación interactiva antes de ejecutar, salvo que uses --yes.
• En --dry-run no modifica el manifiesto ni ejecuta nada.
• Si la base de datos objetivo no existe, falla antes de iniciar el proceso.

innodite:migration-sync — Sincronización Automática de Manifiestos

Escanea los módulos y agrega al manifiesto las migraciones y seeders que aún no están registradas.

Comportamiento de sync:

1. Si no envías --manifest, lee module-maker-config/contexts.json y propone:
   • central_order.json
   • tenant_{permission_prefix}_order.json por cada tenant configurado.
2. Pide confirmación en consola antes de generar/sincronizar múltiples manifiestos (omite prompt con --yes).
3. Crea module-maker-config/migrations/ si no existe.
4. Crea cada manifiesto faltante (estructura vacía).
5. Escanea:
   • Modules/*/Database/Migrations/**
   • Modules/*/Database/Seeders/**
6. Convierte hallazgos a coordenadas.
7. Filtra por alcance de manifiesto:
   • central_order.json => contextos Central y Shared.
   • tenant_*.json => Shared + Tenant/Shared + contexto Tenant/{X} del tenant objetivo.
8. Hace append solo de faltantes (sin duplicar).

Importante:

• Solo sincroniza archivos en subcarpetas de contexto (Shared, Central, Tenant/...).
• Esto mantiene consistencia con el modelo contextual del paquete.

Cuándo usarlo en la práctica:

• Después de generar nuevos módulos/entidades y querer actualizar manifiestos automáticamente.
• Antes de un deploy, para verificar que no quedaron migraciones fuera del plan.
• En CI/CD para detectar drift entre código y manifiesto.

innodite:test-module — Ejecutar Tests con Coverage

Características:

• ✅ Ejecuta PHPUnit en uno o todos los módulos
• ✅ Usa configuración contextual en Modules/{Modulo}/Tests/test-config.json
• ✅ Permite correr un contexto (--context) o todos los contextos habilitados (--all-contexts)
• ✅ Escanea recursivamente toda la carpeta Tests/ sin asumir estructura fija
• ✅ Crea/usa archivo de configuración PHPUnit editable en Modules/{Modulo}/Tests/phpunit-{contexto}.xml
• ✅ Puede ejecutar un seeder previo por contexto antes de PHPUnit
• ✅ Genera reportes de coverage en múltiples formatos:
  • HTML → docs/test-reports/{Module}/{contexto}/html/index.html (navegable)
  • Text → Salida en consola con porcentajes
  • Clover XML → docs/test-reports/{Module}/{contexto}/clover.xml (CI/CD)
• ✅ Valida que Xdebug o PCOV estén activos para coverage
• ✅ Muestra tabla resumen con resultados y porcentaje de cobertura
• ✅ Soporta flag --filter de PHPUnit para tests específicos
• ✅ Detección automática de módulos sin tests (warning + continuar)

innodite:test-sync — Sincronizar Tests/test-config.json

Genera o actualiza el archivo test-config.json dentro de la carpeta Tests/ de cada módulo, leyendo los contextos desde module-maker-config/contexts.json.

Para testing, el sync solo genera contextos válidos de ejecución:

• central
• tenants específicos (tenant_alpha, tenant_beta, etc.)

No genera shared ni tenant_shared, porque esos contextos no representan una base de datos de prueba autónoma.

Reglas del sync:

• ✅ Crea Modules/{Modulo}/Tests/test-config.json si no existe
• ✅ Agrega contextos faltantes sin duplicar
• ✅ Conserva overrides manuales de db_connection, db_database, seeder, enabled y env
• ✅ No asume ninguna base de datos por defecto: tú defines db_connection y db_database

Ejemplo de Modules/User/Tests/test-config.json:

Requisitos para Coverage:

Ejemplo de Salida:

📁 Archivos generados por contexto

Esta sección muestra la lista exacta de archivos que el paquete genera para el módulo User en cada uno de los 4 contextos.

Contexto central — 24 archivos

v3.5.x — Los componentes principales (Model, Controller, Requests, Service, Repository, Migration) se generan dentro de una subcarpeta con el nombre de la entidad: {Tipo}/{Contexto}/{Entidad}/. Las vistas Vue, Tests, Jobs, Notifications y Commands mantienen su estructura anterior (sin subcarpeta de entidad).

Contexto shared — 16 archivos

Contexto tenant_shared — 17 archivos

Contexto tenant (ej: INNODITE) — 20 archivos

🔄 Flujo completo por contexto

Esta sección documenta el flujo de generación completo para cada contexto: qué archivos crea, dónde los ubica y cómo inyecta las rutas.

Contexto central

Ruta inyectada en routes/web.php

Resolución de contextRoute()

Contexto shared

Dualidad de rutas — inyección simultánea en DOS archivos

El contexto shared es único: sus rutas son accesibles tanto desde el panel central como desde el panel tenant. El generador inyecta rutas en dos archivos simultáneamente.

En routes/web.php (acceso desde el panel central):

En routes/tenant.php (acceso desde el panel tenant):

Resolución de contextRoute() en shared

El mismo componente Vue resuelve diferente según el panel activo, gracias a auth.context.route_prefix inyectada por InnoditeContextBridge:

Las vistas Vue no cambian — el composable adapta la ruta automáticamente según el contexto activo en sesión.

Contexto tenant_shared

Ruta inyectada en routes/tenant.php

El contexto tenant_shared tiene route_prefix: null — las rutas se definen sin prefijo URL para que cada tenant acceda directamente bajo su propio dominio.

Nota: Sin route_prefix, el nombre de ruta tampoco lleva prefijo de contexto. contextRoute('roles.index') devuelve simplemente 'roles.index'.

Contexto tenant (tenant específico — ej: INNODITE)

El paquete resuelve innodite buscando en el array tenant de contexts.json por name, class_prefix o slug derivado del nombre.

Ruta inyectada en routes/tenant.php

Resolución de contextRoute()

🧩 Composables Vue 3

Los composables se publican con php artisan innodite:publish-frontend en resources/js/Composables/.

useModuleContext — Detección automática de contexto

Lee auth.context.route_prefix desde las props de Inertia compartidas por InnoditeContextBridge y antepone automáticamente el prefijo correcto a cualquier clave de ruta.

El mismo componente Vue funciona en cualquier contexto sin cambios — el composable resuelve la ruta correcta según la sesión activa.

usePermissions — Verificación de permisos del usuario

Lee auth.permissions desde las props de Inertia y permite verificar permisos de forma declarativa en las plantillas Vue.

Estrategia dual: verifica {prefix}.{perm} y {perm} plano simultáneamente. El mismo componente funciona en cualquier contexto sin cambios.

Flujo de datos en las vistas Vue generadas

Ejemplo — CentralUserIndex.vue

Ejemplo — CentralUserCreate.vue

• Errores de validación Laravel 422 mostrados campo a campo
• Botón deshabilitado durante el envío (previene doble submit)

Ejemplo — CentralUserEdit.vue

• Recibe solo id como prop de Inertia (nunca el objeto completo)
• Carga el registro vía axios al montarse

🔧 Stubs contextuales

El sistema de stubs de v3.1.0 organiza las plantillas en 4 carpetas independientes, una por contexto. Esto permite personalizar la salida generada para cada contexto sin afectar los demás.

Estructura de stubs

Publicar stubs para personalización

Copia las 4 carpetas de stubs a module-maker-config/stubs/contextual/ en tu proyecto. A partir de ese momento, el generador usará tus stubs en lugar de los del paquete.

Variables disponibles en los stubs

🌉 Bridge Frontend-Backend

Middleware InnoditeContextBridge

Intercepta cada request e inyecta vía Inertia::share():

Cadena de resolución de permisos:

1. Spatie Permission → $user->getAllPermissions()->pluck('name')
2. InnoditeUserPermissions → $user->getInnoditePermissions()
3. Fail-safe → [] + Warning en log

Registrar en bootstrap/app.php (Laravel 11+):

Alias para rutas específicas:

Interfaz InnoditeUserPermissions

⚙️ Estructura de contextos (contexts.json)

El array tenant puede contener múltiples entradas, una por cada tenant específico del proyecto. Cada entrada genera su propio espacio de nombres, carpetas y marcador de rutas aislado.

Claves del contexto tenant_shared con route_prefix: null

Es el único contexto sin prefijo de URL ni de nombre de ruta. contextRoute('roles.index') devuelve simplemente 'roles.index' — diseñado para código estándar que se ejecuta bajo el dominio de cada tenant.

🌳 Estructura de árbol de un módulo generado

El siguiente árbol corresponde a innodite:make-module User --context=central (módulo completo, 24 archivos).

Patrón v3.5.x: Los componentes principales siguen {Tipo}/{Contexto}/{Entidad}/{Archivo}.

Con innodite:add-entity User Role --context=central, se añade dentro de Modules/User/ una subcarpeta Role/ paralela a User/ en cada tipo de componente.

📐 Convenciones de nomenclatura

Reglas adicionales:

• El nombre del módulo siempre va en PascalCase (ej: User, InvoiceItem, TaxReport)
• Las migraciones son anónimas (return new class extends Migration) para evitar colisiones de nombres
• Los ServiceProviders llevan el nombre del módulo sin prefijo de contexto (UserServiceProvider, no CentralUserServiceProvider)
• Los Seeders, Jobs, Notifications y Commands sí llevan prefijo de contexto a partir de v3.1.0

🔀 Flujo de inyección de rutas

Marcadores en routes/web.php

Marcadores en routes/tenant.php

Proceso interno de inyección

Contexto shared — Dualidad de rutas

📋 Resumen de todos los comandos

📊 Auditoría

storage/logs/module_maker.log — formato NDJSON (una entrada JSON por línea):

🧪 Pruebas

Los tests generados por make-module se ubican en:

• Modules/{Name}/Tests/Feature/{Context}/ — tests de integración HTTP
• Modules/{Name}/Tests/Unit/{Context}/ — tests unitarios del servicio
• Modules/{Name}/Tests/Support/{Context}/ — helpers y factories de test

📏 Estándares de código

El paquete incluye configuración de PHP CS Fixer compatible con PSR-12. Todos los archivos PHP generados incluyen declare(strict_types=1) por defecto.

📦 Publicar en Packagist / repositorio privado

Repositorio público (Packagist)

Luego registrar el repositorio en packagist.org con la URL del repositorio.

Repositorio privado (VCS)

Agregar en el composer.json del proyecto consumidor:

📝 Changelog

Ver CHANGELOG.md para el historial completo de versiones.

📄 Licencia

MIT — Anthony Filgueira