Nuxt Module Federation

Use Module Federation in Nuxt applications with @module-federation/nuxt, built on top of @module-federation/vite.

Important

@module-federation/nuxt is still in beta. Expect API changes while the integration settles. Please report bugs and edge cases in this repository.

What you get

• Nuxt module wiring for Module Federation hosts and remotes.
• Convention-based component exposes from ~/components/exposed.
• Remote Vue components registered in Nuxt for template auto-imports.
• Server-rendered remote components in development and production on writable Node deployments.
• Client and server remote entries plus an MF manifest at the public root.
• vue and vue-router shared as singletons by default.

Install

pnpm add @module-federation/nuxt

Add the module to both the host and remote applications.

Remote

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ["@module-federation/nuxt"],
  moduleFederation: {
    config: {
      name: "remote",
    },
  },
});

Components placed in app/components/exposed are exposed automatically. For example, app/components/exposed/Widget.vue becomes ./Widget.

Host

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

Use the remote as a normal Nuxt component:

<template>
  <RemoteWidget />
</template>

remoteComponents keeps component registration deterministic when the remote manifest is unavailable during startup. When the manifest is available, the module also discovers its component exposes automatically.

See packages/nuxt/README.md for the complete option reference, component naming rules, sharing behavior, and deployment contract.

Server rendering

Remote components render on the Nuxt server by default. Production remotes publish both remoteEntry.js and remoteEntry.ssr.js; the host loads the server entry while rendering and hydrates the same component in the browser.

The default upstream SSR loader writes fetched modules to node_modules/.ssr-cache below the server working directory. Use moduleFederation.ssr: false for read-only or serverless deployments; see the package deployment contract for details.

Nuxt 4.5 uses Vite 8's Rolldown pipeline. The MF server runner uses its ModuleRunner protocol, so remote components render during nuxt dev as well as production. Set moduleFederation.ssr to false to choose client-only rendering in every environment.

Example applications

• Host: apps/host at http://localhost:4173
• Remote: apps/remote at http://localhost:4174

Run both from the repository root:

pnpm install
pnpm dev

Or run one side:

pnpm dev:remote
pnpm dev:host

The ports are fixed because the host's remote URL depends on the remote remaining at 4174.

Build checks

pnpm typecheck
pnpm build
pnpm test
pnpm test:e2e
pnpm pack:nuxt

For a production smoke test, start both built applications with pnpm preview, then open http://localhost:4173 and confirm the remote cards are present before hydration and remain interactive afterward.

Release flow

• Versioning: Changesets (pnpm changeset)
• Version PR: GitHub Actions Release Pull Request
• Publish: GitHub Actions Release
• Release procedure: docs/RELEASING.md

Repository layout

• Package: packages/nuxt
• Host example: apps/host
• Remote example: apps/remote
• Package reference: packages/nuxt/README.md
• Release guide: docs/RELEASING.md