Reglas de independencia

Prefijos de tabla, comportamiento al desinstalar, módulos hijos y los estados de compatibilidad, en detalle.

El kernel impone esto. Existe para que un comprador pueda instalar, desactivar y eliminar cualquier módulo sin poner nunca en riesgo el core.

1. Tus tablas, y solo tus tablas#

Cada tabla que crean tus migraciones lleva el prefijo mod_<slug>_, con los guiones convertidos en guiones bajos. Para un módulo con slug members-plus, eso es mod_membersplus_ o mod_members_plus_ según el slug que hayas elegido, y se verifica en el momento de instalar.

Leer datos del core está permitido. Las escrituras estructurales a cualquier cosa fuera de tu prefijo no lo están, y un paquete cuyas migraciones llegan afuera se rechaza.

2. Desinstalar elimina tu módulo y nada más#

onUninstall(bool $purge) elimina tus tablas y borra tus registros de migración. El core queda intacto, así que reinstalar empieza de cero.

Desactivar es la operación reversible: no se borra nada y el módulo vuelve exactamente como estaba. Asegúrate de que onDisable() no haga ninguna limpieza que onEnable() no pueda deshacer.

3. Nada de claves foráneas entre módulos#

Nunca apuntes una clave foránea a la tabla de otro módulo. Ese módulo se puede desinstalar mientras el tuyo sigue corriendo, y una restricción colgante tumbaría todo el sitio.

Usa en su lugar una referencia polimórfica con un alias de string, y resuélvela mediante una guarda.

4. Archivos de idioma propios#

Código

modules/<slug>/resources/lang/en/<file>.php

Se cargan bajo un namespace y se referencian como slug::file.key. Nada tuyo entra en los archivos de idioma del core, y cada string se escribe en inglés.

5. La falla está aislada#

El boot es resistente: un módulo que lanza una excepción se salta y el request continúa. No confíes en esto como manejo de errores, pero sí confía en la garantía que le da a tus compradores.

6. Módulos hijos#

parent: "<slug>" declara que tu módulo extiende otro módulo en lugar del core.

Un hijo requiere que su padre esté instalado y activo.
Desactivar el padre desactiva a sus hijos en cascada.
Desinstalar un padre se bloquea mientras un hijo esté instalado.
Los hijos aparecen indentados bajo su padre en el panel.

Los gateways de pago son el ejemplo canónico: cada uno es hijo de payments y registra su driver solo mientras el padre está activo.

7. Estados de compatibilidad#

Estado	Disparador	Efecto
Actualizado	`tested_up_to` está al nivel o por encima del core en ejecución	Normal
Desactualizado	`tested_up_to` está por debajo del core en ejecución	Aviso ámbar, sigue funcionando
Incompatible	Una entrada de `requires` ya no se cumple	Desactivado al iniciar, no se puede activar hasta actualizarlo

Mantén tested_up_to honesto. Es lo que le dice a un comprador si debe esperar problemas.

8. Tus propias configuraciones#

Un módulo puede tener sus propias pantallas de configuración, independientes de las del core. Declara el nombre de la ruta en settings en el manifiesto y el listado de módulos muestra el atajo mientras el módulo esté activo.

Checklist#

Tablas con prefijo y eliminadas al desinstalar.
Nada de claves foráneas a otro módulo.
Cada string en tus propios archivos de idioma, escrito en inglés.
Cada llamada entre módulos detrás de class_exists o Route::has.
Assets compilados dentro del paquete, sin build en el host del comprador.
Nada de script en línea en ningún lado.