Runtime Plugins
Los runtime plugins te permiten cambiar el comportamiento en runtime sin modificar el propio núcleo del runtime.
Úsalos cuando necesites:
- reescribir URLs de remotes en runtime
- personalizar las solicitudes del manifest
- modificar la carga de scripts
- sobrescribir la resolución de shared
- añadir comportamientos de recuperación o fallback
- introducir nuevos comportamientos de carga de remotes
Si solo necesitas registrar la ruta de un plugin en la configuración de build, consulta runtimePlugins. Si necesitas la lista completa de hooks, consulta Runtime Hooks.
Modelo mental
Un runtime plugin es una función que devuelve un ModuleFederationRuntimePlugin.
Los plugins nuevos deben devolver sus hooks desde apply(instance):
La forma de función es importante porque te permite:
- aceptar opciones
- mantener estado en un closure
- reutilizar la misma lógica del plugin en distintos entornos
Registrar un plugin
Puedes registrar runtime plugins en tres lugares:
- En tiempo de build, mediante
runtimePlugins - En runtime, en una instancia concreta, mediante
registerPlugins(...)oinstance.registerPlugins(...) - En runtime, de forma global, mediante
registerGlobalPlugins(...)
Registro en tiempo de build
Usa el registro en tiempo de build cuando el plugin deba estar siempre presente para ese host.
Registro en runtime
Usa el registro en runtime cuando el plugin dependa del estado del usuario, del entorno, de feature flags o de datos obtenidos después del arranque.
Registro global en runtime
Usa registerGlobalPlugins(...) cuando quieras que el plugin esté disponible para todas las instancias de runtime futuras, y no solo para la instancia actual.
Es lo más adecuado para instrumentación compartida, políticas entre aplicaciones o valores por defecto para todo el host.
registerGlobalPlugins(...) elimina los plugins duplicados según su name. En la práctica, llámalo antes de crear o usar instancias de runtime para que los plugins globales se incorporen de forma coherente.
Acceder a la instancia de runtime desde un plugin
Antes, solo unos pocos hooks recibían la instancia de runtime como argumento. Si un
plugin necesita acceder a su instancia de runtime desde cualquier hook, implementa
apply(instance). Se llama una vez por nombre de plugin en cada instancia; ahí el
plugin puede acceder a la instancia actual y devolver los hooks que se registrarán para ella.
La instance que se pasa a apply(instance) es la instancia de runtime actual. Úsala
para leer información de la instancia o llamar a sus métodos. Como cada instancia
llama a apply por separado, los contadores, cachés y suscripciones declarados ahí
también permanecen aislados. El objeto devuelto es el conjunto de hooks registrado para esa
instancia.
Sintaxis heredada y compatibilidad
Antes, los hooks podían declararse directamente en el objeto del plugin:
Esta sintaxis sigue siendo compatible, pero quedará obsoleta. Para migrar, mueve los
hooks existentes al objeto devuelto por apply(instance). Cuando apply
no devuelve nada, la versión actual sigue recurriendo a los hooks declarados en el
objeto del plugin.
Elegir el hook adecuado
Receta: reescribir la remote entry resuelta
afterResolve es el hook adecuado cuando el remote ya se ha resuelto y quieres cambiar la URL final antes de que continúe la carga.
Este patrón es útil para:
- indirección mediante CDN
- cambio de entorno
- enrutamiento basado en un registro
- normalización de dominios
Por qué este hook:
beforeRequestse ejecuta antes; el remote todavía no está resueltoafterResolveya te proporcionaremoteInfo.entry- cambiar
args.remoteInfo.entryaquí mantiene intactos la ruta, la query y el hash originales
Reescribir con afterResolve cambia el comportamiento de carga en runtime. No reescribe automáticamente la URL del remote que usan la generación de tipos u otras herramientas de tiempo de build. Si dependes de los tipos generados de los remotes, mantén esa ruta alineada por separado.
Receta: personalizar el fetch del manifest
Usa fetch cuando la propia solicitud del manifest necesite un comportamiento personalizado.
Usa fetch para:
- credenciales
- cabeceras de autenticación
- reintentos del manifest
- lógica de proxy personalizada
Si necesitas una política de transporte ya preparada, consulta el retry plugin integrado.
Receta: preferir una dependencia shared propiedad del host
resolveShare es el hook para sobrescribir la selección final del módulo shared.
Lo importante: cambiar solo args.scope o args.version no es suficiente. Para cambiar realmente el shared elegido, reemplaza args.resolver.
Gestión de fallos y shareStrategy
errorLoadRemote es el lugar adecuado para los fallbacks en runtime.
Un detalle importante: el comportamiento cambia según shareStrategy.
version-firstcarga de forma anticipada las remote entries durante el arranque para inicializar las dependencias sharedloaded-firstaplaza la carga del remote hasta que realmente se usa
Eso significa que:
- con
version-first, un remote sin conexión puede fallar pronto conlifecycle: 'beforeLoadShare' - con
loaded-first, el mismo remote suele fallar más tarde, cuando el código intenta usarlo realmente
Si esperas que los remotes no estén disponibles de forma intermitente, combina errorLoadRemote con una shareStrategy elegida a conciencia.
Hooks sensibles a la versión
Los hooks avanzados evolucionan con el tiempo. Para hooks habituales como afterResolve, fetch, createScript y loadEntry, es preferible revisar los tipos del runtime instalado cuando dependas de argumentos o comportamientos más recientes.
Esto es especialmente relevante cuando dependes de:
- atributos de script adicionales en
createScript - detalles de los hooks del loader que se pasan a
fetcholoadEntry - hooks de ciclo de vida menos comunes que usan los plugins integrados