#Nuxt

@module-federation/nuxt es un módulo de Nuxt que integra Module Federation en hosts y remotes de Nuxt. Usa @module-federation/vite con el builder de Vite que Nuxt trae por defecto, o @module-federation/enhanced/rspack cuando la aplicación usa el builder de Rspack, de modo que configuras la federación una sola vez en nuxt.config.ts, sea cual sea el builder.

#Compatibilidad

• Nuxt >=4.5.1 con el builder de Vite predeterminado o un @nuxt/rspack-builder de la versión correspondiente
• Node.js ^22.18.0, ^24.11.0 o >=26.0.0
• Componentes remotos renderizados en el servidor, en desarrollo y en producción, en despliegues de Node con permisos de escritura
• Exposes de componentes basados en convenciones desde ~/components/exposed
• Componentes Vue remotos registrados para los auto-imports de plantillas de Nuxt
• vue y vue-router compartidos como singletons por defecto

#Instalación

Instala el módulo tanto en el host como en el remote:

npm add @module-federation/nuxt

yarn add @module-federation/nuxt

pnpm add @module-federation/nuxt

bun add @module-federation/nuxt

#Configurar un remote

Registra el módulo y asigna un nombre único a cada contenedor desplegado:

export default defineNuxtConfig({
  modules: ['@module-federation/nuxt'],
  moduleFederation: {
    config: {
      name: 'catalog',
    },
  },
});

Los componentes ubicados en app/components/exposed se exponen automáticamente. Por ejemplo, app/components/exposed/ProductCard.vue se expone a los hosts como ./ProductCard.

También puedes configurar exposes directamente. Las rutas relativas se resuelven desde la raíz de la aplicación Nuxt:

export default defineNuxtConfig({
  modules: ['@module-federation/nuxt'],
  moduleFederation: {
    config: {
      name: 'catalog',
      exposes: {
        './catalog-app': './app/app.vue',
      },
    },
  },
});

#Configurar un host

export default defineNuxtConfig({
  modules: ['@module-federation/nuxt'],
  moduleFederation: {
    remoteComponents: {
      catalog: ['ProductCard'],
    },
    config: {
      name: 'shell',
      hostInitInjectLocation: 'entry',
      remotes: {
        catalog: {
          type: 'module',
          name: 'catalog',
          entry: 'https://catalog.example.com/mf-manifest.json',
          entryGlobalName: 'catalog',
          shareScope: 'default',
        },
      },
    },
  },
});

A continuación, el componente expuesto está disponible mediante los auto-imports de componentes de Nuxt:

<template>
  <RemoteProductCard product-id="123" />
</template>

Durante la configuración, el módulo obtiene el mf-manifest.json de cada remote y registra sus exposes de componentes. remoteComponents es la lista de respaldo que se usa cuando no se puede acceder al manifest, por ejemplo, cuando el remote se despliega por separado del build del host.

En los hosts con SSR, es preferible usar URLs de manifest: el runtime usa el manifest para elegir la entrada del navegador o del servidor, y puede detectar un nuevo build del servidor sin reiniciar el host.

#Nombres de los componentes

Con un único remote, ./ProductCard se convierte en RemoteProductCard. Con varios remotes, se incluye el nombre del remote para evitar colisiones, así que catalog/ProductCard se convierte en RemoteCatalogProductCard.

Solo se registran como componentes de Nuxt los exposes cuyo nombre empieza por una letra y contiene letras, números, guiones bajos o guiones. Los demás exposes siguen disponibles mediante imports normales en runtime.

#Renderizado en el servidor

Por defecto, los componentes remotos se renderizan en el servidor de Nuxt. Un remote de producción publica tanto remoteEntry.js para el navegador como remoteEntry.ssr.js para el servidor; el host carga la entrada del servidor durante el renderizado, incluye el HTML del remote en su respuesta e hidrata el mismo componente en el navegador.

El loader de SSR predeterminado escribe los módulos obtenidos en node_modules/.ssr-cache, dentro del directorio de trabajo del servidor. En despliegues de solo lectura o serverless, desactiva el SSR de los remotes:

export default defineNuxtConfig({
  moduleFederation: {
    ssr: false,
    config: {
      // ...
    },
  },
});

Si un remote falla durante una petición en el servidor, el host renderiza un fallback vacío para esa petición de modo que la página siga respondiendo, y las peticiones posteriores vuelven a intentar cargar el remote.

#Dependencias compartidas

Cuando config.shared no está definido, vue y vue-router se comparten como singletons usando sus versiones instaladas. Define config.shared para sobrescribir los valores por defecto:

export default defineNuxtConfig({
  moduleFederation: {
    config: {
      shared: {
        vue: { singleton: true, requiredVersion: '^3.5.0' },
        'vue-router': { singleton: true, requiredVersion: '^5.1.0' },
        pinia: { singleton: true },
      },
    },
  },
});

#Usar el builder de Rspack

Vite es el builder predeterminado. Para usar Rspack, instala @nuxt/rspack-builder con la misma versión que Nuxt y define builder: 'rspack' en la aplicación:

export default defineNuxtConfig({
  builder: 'rspack',
  modules: ['@module-federation/nuxt'],
  moduleFederation: {
    config: { name: 'catalog' },
  },
});

Ambos builders usan la misma configuración de moduleFederation y pueden consumir los manifests del otro. Rspack ignora las opciones exclusivas de Vite, como hostInitInjectLocation.

#Opciones

Configura estos valores en moduleFederation dentro de nuxt.config.ts:

Consulta la referencia del paquete para ver los componentes remotos tipados, las exportaciones de aplicaciones con Bridge y el contrato de despliegue completo.

#Ejemplos

• Aplicaciones de ejemplo de module-federation/nuxt: hosts y remotes con Vite y Rspack
• Host y remote con Nuxt: Nuxt 4 con componentes remotos con SSR