#Nuxt

@module-federation/nuxt é um módulo do Nuxt que integra o Module Federation a hosts e remotes Nuxt. Ele usa o @module-federation/vite com o builder Vite padrão do Nuxt, ou o @module-federation/enhanced/rspack quando a aplicação usa o builder Rspack. Assim, você configura a federação uma única vez no nuxt.config.ts, independentemente do builder.

#Suporte

• Nuxt >=4.5.1 com o builder Vite padrão ou um @nuxt/rspack-builder de versão correspondente
• Node.js ^22.18.0, ^24.11.0 ou >=26.0.0
• Componentes remotos renderizados no servidor, em desenvolvimento e em produção, em deploys Node com sistema de arquivos gravável
• Exposes de componentes por convenção a partir de ~/components/exposed
• Componentes Vue remotos registrados nos auto-imports de templates do Nuxt
• vue e vue-router compartilhados como singletons por padrão

#Instalação

Instale o módulo tanto no host quanto no remote:

npm add @module-federation/nuxt

yarn add @module-federation/nuxt

pnpm add @module-federation/nuxt

bun add @module-federation/nuxt

#Configurar um remote

Registre o módulo e dê a cada container publicado um nome único:

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

Os componentes colocados em app/components/exposed são expostos automaticamente. Por exemplo, app/components/exposed/ProductCard.vue é exposto aos hosts como ./ProductCard.

Você também pode configurar exposes diretamente. Caminhos relativos são resolvidos a partir da raiz da aplicação Nuxt:

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

#Configurar um 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',
        },
      },
    },
  },
});

O componente exposto fica então disponível por meio dos auto-imports de componentes do Nuxt:

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

Durante o setup, o módulo busca o mf-manifest.json de cada remote e registra seus exposes de componentes. remoteComponents é a lista de fallback usada quando o manifest não pode ser acessado, por exemplo quando o remote é publicado separadamente do build do host.

Prefira URLs de manifest em hosts com SSR: o runtime usa o manifest para escolher o entry do navegador ou do servidor e consegue detectar um novo build de servidor sem reiniciar o host.

#Nomes dos componentes

Com um único remote, ./ProductCard vira RemoteProductCard. Com vários remotes, o nome do remote é incluído para evitar colisões, então catalog/ProductCard vira RemoteCatalogProductCard.

Apenas exposes cujos nomes começam com uma letra e contêm letras, números, underscores ou hífens são registrados como componentes do Nuxt. Os demais exposes continuam disponíveis por meio de imports normais em runtime.

#Renderização no servidor

Por padrão, os componentes remotos são renderizados no servidor do Nuxt. Um remote de produção publica tanto o remoteEntry.js para o navegador quanto o remoteEntry.ssr.js para o servidor; o host carrega o entry de servidor durante a renderização, inclui o HTML do remote na resposta e faz a hidratação do mesmo componente no navegador.

O loader de SSR padrão grava os módulos baixados em node_modules/.ssr-cache, abaixo do diretório de trabalho do servidor. Em deploys somente leitura ou serverless, desative o SSR de remotes:

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

Se um remote falhar durante uma requisição no servidor, o host renderiza um fallback vazio para essa requisição, de modo que a página continue respondendo, e as requisições seguintes tentam carregar o remote novamente.

#Dependências compartilhadas

Quando config.shared não está definido, vue e vue-router são compartilhados como singletons usando as versões instaladas. Defina config.shared para substituir esses padrões:

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 o builder Rspack

O Vite é o padrão. Para usar o Rspack, instale o @nuxt/rspack-builder na mesma versão do Nuxt e defina builder: 'rspack' na aplicação:

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

Os dois builders usam a mesma configuração moduleFederation e conseguem consumir os manifests um do outro. Opções exclusivas do Vite, como hostInitInjectLocation, são ignoradas pelo Rspack.

#Opções

Configure estes valores em moduleFederation no nuxt.config.ts:

Consulte a referência do pacote para componentes remotos tipados, exports de aplicações Bridge e o contrato completo de deploy.

#Exemplos

• Aplicações de exemplo do module-federation/nuxt: hosts e remotes com Vite e Rspack
• Host e remote Nuxt: Nuxt 4 com componentes remotos renderizados via SSR