# Module federation

> Module Federation is a concept that allows developers to share code and resources across multiple JavaScript applications

## Guide

- [Shared Dependency Isolation: Multiple Share Scopes](/guide/advanced/multiple-shared-scope.md): Split shared dependencies into multiple named shared pools (for example default, scope1). Dependencies are only reused within the same pool.
- [Module Federation for AI](/guide/ai/index.md)
- [Skills](/guide/ai/skill.md): Module Federation provides a set of Agent Skills — loadable instruction sets for AI coding assistants that give them built-in knowledge of Module Federation 2.0 internals. These skills help you diagnose configuration issues, resolve type errors, detect shared dependency conflicts, and more, all within your editor.
- [Command Line Tool](/guide/basic/cli.md): {props.name || 'Module Federation'} provides lightweight command-line tools: {(props.cmdTools || ['@module-federation/enhanced', '@module-federation/modern-js-v3']).map((cmdTool,index,arr)=>(<><code>{cmdTool}</code>{index+1===arr.length ? '':' and '}</>))} .
- [Style Isolation](/guide/basic/css-isolate.md): To achieve CSS style isolation, the following methods can be used. Here are the detailed usage instructions for each method:
- [Data Caching](/guide/basic/data-fetch-cache.md): The cache function allows you to cache the results of data fetching or computations. It provides fine-grained control over data and is suitable for various scenarios, including Client-Side Rendering (CSR), Server-Side Rendering (SSR), and API services (BFF).
- [Prefetch](/guide/basic/data-fetch-prefetch.md): The prefetch function is used to pre-fetch resources and data for remote modules, thereby improving application performance and user experience. By pre-loading required content before a user accesses a feature, waiting times can be significantly reduced. {props.prefetchTip || React.createElement(PrefetchTip)}
- [Data Fetching](/guide/basic/data-fetch.md): :::tip
Data Loader supports both SSR and CSR scenarios! Demo :::
- [Type Hinting](/guide/basic/type-prompt.md): Just like an NPM Package, {props.name || 'Module Federation'} artifacts also generate types and enjoy hot-reloading of types, even though the artifacts are hosted on a remote CDN. <code>{props.pkgName || '@module-federation/enhanced'}</code> has type hinting enabled by default. This article will introduce several common usage scenarios and their specific configurations.
- [Metro](/guide/build-plugins/plugins-metro.md): Metro Module Federation brings the power of distributed architecture to React Native mobile development.
- [Rsbuild](/guide/build-plugins/plugins-rsbuild.md): Help users quickly build Module Federation products in Rsbuild App or Rslib
- [Rspack](/guide/build-plugins/plugins-rspack.md): Capable of building modules that meet the <code>{props.brandName || props.name || 'Module Federation'}</code> loading specifications.Can consume modules that adhere to the <code>{props.brandName || props.name || 'Module Federation'}</code> specifications using aliases.Can set shared dependency configurations for modules, so that when the host environment of the loaded module already has the corresponding dependency, it will not be loaded again.When a module has remote types, it will automatically download and consume the types of the remote modules.Consuming remote modules will have hot update capabilities. {props.tip}
- [Rspress](/guide/build-plugins/plugins-rspress.md): :::info Note
Requires Rspress version 2.0.0-beta.16 or higher.
::: Helps users build and consume {props.brandName || props.name || 'Module Federation'} products in Rspress.
- [Vite](/guide/build-plugins/plugins-vite.md): Can build modules that meet the Module Federation loading specifications.Can consume modules that adhere to the Module Federation specifications using aliases.Can configure shared dependencies for modules, so that when the host environment of the loaded module already has the corresponding dependency, it will not be loaded again.When a module has remote types, it automatically downloads and consumes the remote types. :::warning Unsupported Options
Except for the dev option, all options are supported.
::: roadmap 🗓️Consuming remote modules will have hot update capabilities.nuxt ssr
- [Webpack](/guide/build-plugins/plugins-webpack.md): Capable of building modules that meet the {props.brandName || props.name || 'Module Federation'} loading specification.Capable of consuming modules of the {props.brandName || props.name || 'Module Federation'} specification using aliases.Capable of setting the shared dependency configuration for modules. When the host environment where the module is loaded already has the corresponding dependency, it will not be loaded repeatedly.When a module has a remote type, the type of the remote module will be automatically downloaded for consumption.Hot-reloading capability when consuming remote modules. {props.tip}
- [Overview](/guide/build-plugins/plugins.md): { props.name || 'Module Federation' } provides build plugins for different bundlers. Read the plugin documentation for your bundler to integrate and configure MF in your project. Plugins for different bundlers may include a few bundler-specific options, but the core configuration stays consistent. See Configuration.
- [Chrome Devtool](/guide/debug/chrome-devtool.md): The Micro-frontend architecture differs from the traditional monolithic application development model. Its characteristics of separate development, deployment, and debugging require a new set of debugging tools to meet new usage scenarios, such as: how to verify the effect of modules in actual projects during Module Federation development, whether the dependencies of Module Federation are reused with the host environment, which Module Federation modules are loaded on the current page, the dependency relationships of Module Federation, and how data flows between Module Federation modules. Chrome Devtool provides the following capabilities: Supports Module Federation proxy function, proxying online page Module Federation to user local Module Federation.Switch online page Module Federation versions for quick functional verification.Support viewing module dependency information.Support filtering specified module dependency information. ::: tip Limitations of Chrome Devtool: You must use mf-manifest.json to use the visualization and proxy capabilities provided by Chrome devtool. :::
- [Enable debug mode](/guide/debug/mode.md): To facilitate troubleshooting, {props.name || 'Module Federation'} provides a debug mode. You can add the FEDERATION_DEBUG=true environment variable when executing a build or execute localStorage.setItem('FEDERATION_DEBUG','true') in the browser to enable the debug mode of Module Federation. Build and add environment variables: Runtime and add environment variables:
- [Global variables](/guide/debug/variables.md): :::note
Global variables are readable only, do not modify them!
:::
- [Deploy with Zephyr Cloud](/guide/deployment/zephyr.md): Zephyr Cloud is a zero-config deployment platform that integrates directly into your build process and provides global edge distribution for Module Federation applications. How to deploy Install the Zephyr plugin for your bundler (supports Webpack, Rspack, Vite, etc...): <InstallKit
pkgName="zephyr-webpack-plugin"
/> Add the plugin to your webpack configuration: Build your project as usual: During the build process, your Module Federation application will be automatically deployed to Zephyr's global edge network and you'll receive a deployment URL. Zephyr Cloud handles asset optimization, dependency resolution, and provides automatic rollback capabilities for your micro-frontend applications.
- [Modern.js](/guide/framework/modernjs.md): Modern.js is a progressive web development framework based on React. Internally at ByteDance, Modern.js supports the development of thousands of web applications. The Module Federation team works closely with the Modern.js team and provides the @module-federation/modern-js-v3 plugin to help users better utilize Module Federation within Modern.js.
- [Next.js](/guide/framework/nextjs.md): :::danger Project Deprecation
Support for Next.js is ending read more
::: This plugin enables Module Federation on Next.js
- [Shared Tree Shaking](/guide/performance/shared-tree-shaking.md)
- [Runtime Access](/guide/runtime/index.md): :::tip Before reading this chapter, it is assumed that you already understand: The features and capabilities of Module FederationThe glossary of Module FederationHow to consume and export modules ::: Currently, Module Federation provides two ways to register and load modules: One is to declare it in the build plugin (usually in the module-federation.config.ts file)The other way is to directly register and load modules through the runtime API. The two modes are not conflicting and can be used together. You can flexibly choose the module registration method and timing according to your actual scenario. If the build plugin is used, an MF instance will be automatically created and stored in memory when the project starts. You can directly call methods of the MF instance via the . If the build plugin is not used, you need to manually create an MF instance before calling the corresponding API. What is a ModuleFederation instance? A ModuleFederation instance is an instance of the ModuleFederation class, which contains all the functionality of the ModuleFederation runtime. You can enter __FEDERATION__.__INSTANCES__ in the console to view the created instances.
- [Runtime API](/guide/runtime/runtime-api.md): If the build plugin is used, an MF instance will be automatically created and stored in memory when the project starts. You can directly call methods of the MF instance via the . If the build plugin is not used, you need to manually create an MF instance before calling the corresponding API. What is a ModuleFederation instance? A ModuleFederation instance is an instance of the ModuleFederation class, which contains all the functionality of the ModuleFederation runtime. You can enter __FEDERATION__.__INSTANCES__ in the console to view the created instances.
- [Runtime Hooks](/guide/runtime/runtime-hooks.md)
- [Feature Navigation](/guide/start/features.md): Here, you will discover the key functionalities offered through Module Federation. This version of Module Federation, distinct from those integrated into Webpack and Rspack, leverages the advanced features of the bundler tool. It offers enhanced capabilities designed to fulfill more demanding requirements of large-scale application development.
- [Glossary of Terms](/guide/start/glossary.md)
- [Introduction](/guide/start/index.md): 💡 What is Module Federation? Module Federation is an architectural pattern for the decentralization of JavaScript applications (similar to microservices on the server-side). It allows you to share code and resources among multiple JavaScript applications (or micro-frontends). This can help you: Reduce code duplicationImprove code maintainabilityLower the overall size of your applicationsEnhance the performance of your applications ✨ What is Module Federation 2.0? Module Federation 2.0 differs from the Module Federation built into Webpack5 by providing not only the core features of module export, loading, and dependency sharing but also additional dynamic type hinting, Manifest, Federation Runtime, and Runtime Plugin System. These features make Module Federation more suitable for use as a micro-frontend architecture in large-scale Web applications. 🔥 Features Module Federation has the following features: ⚡ Code sharing, Dependency reuse📝 Manifest🎨 Module Federation Runtime🧩 Runtime Plugins System🚀 Dynamic type prompt🛠️ Chrome Devtool🦀 Rspack and Webpack Support 🎯 Use Cases Module Federation is suitable for the following scenarios: Large Applications: For large applications, you can break the application into multiple micro-frontends and use Module Federation to share code and resources between them.Microfrontend Architecture: Module Federation is an ideal tool for building microfrontend architectures.Multi-team Development: Module Federation can assist multiple teams in collaboratively developing large applications. 🕠 History of Module Federation Module Federation is a new feature introduced in Webpack 5, but its history dates back to 2017. At that time, the Webpack team began exploring a way to share code between multiple applications. In 2018, Webpack 4.20 was released, introducing module hooks, which laid the foundation for the development of Module Federation.In 2019, Webpack 5 was released, officially introducing the Module Federation feature. Module Federation has become a powerful tool for building modern web applications. 🕰️ The Future of Module Federation Module Federation aims to become an architectural method for building large web applications, similar to microservices in the backend. Module Federation will provide more capabilities to meet the foundational needs of large web application decentralization, currently including these parts: Providing comprehensive Devtool toolsOffering more high-level framework capabilities like Router, Sandbox, SSRProviding best practices for large web applications based on Module Federation
- [npm Packages](/guide/start/npm-packages.md): This document showcases all npm package information maintained by the Module Federation team.
- [Quick Start Guide](/guide/start/quick-start.md): Before reading this guide, please first read the Setting Up Environment. This guide will lead you step by step to learn how to use Module Federation. We will build two independent Single Page Applications (SPAs) that will share components using Module Federation. If you encounter unfamiliar terms in the following text, please refer to the Glossary.
- [Setting Up the Environment](/guide/start/setting-up-env.md): Module Federation is a JavaScript application partitioning architecture pattern (similar to microservices on the server side) that allows you to share code and resources between multiple JavaScript applications (or micro frontends). This document is aimed at beginner users and will guide you through setting up the basic environment for Module Federation.
- [Build](/guide/troubleshooting/build.md): This page collects build-time error codes and common troubleshooting guidance.
- [Runtime](/guide/troubleshooting/runtime.md): This page collects runtime-related error codes and common troubleshooting guidance.
- [Types](/guide/troubleshooting/type.md): Type errors are divided into two types: fixed error code errors and scenario-related errors.

## Practice

- [Bridge Overview](/practice/bridge/overview.md)
- [Export Applications](/practice/bridge/react-bridge/export-app.md): This chapter will introduce how to use createBridgeComponent to export your React application as a module that can be loaded remotely.
- [React Bridge Overview](/practice/bridge/react-bridge/getting-started.md): @module-federation/bridge-react is a powerful micro-frontend solution designed specifically for React applications. By providing cross-framework rendering and routing coordination capabilities, you can easily export and load React applications or modules as standalone applications.
- [Loading Applications](/practice/bridge/react-bridge/load-app.md): This chapter introduces how to use createRemoteAppComponent to load and integrate remote React applications in a host application.
- [Loading Components](/practice/bridge/react-bridge/load-component.md): This chapter will introduce how to use createLazyComponent to load and integrate remote React component modules in host applications.
- [Vue Bridge (for Vue v3)](/practice/bridge/vue-bridge.md): @module-federation/bridge-vue3 provides a bridge utility function for Vue V3 applications. The provided createBridgeComponent can be used to export application-level modules, and createRemoteAppComponent can be used to load application-level modules. Installation <PackageManagerTabs
command={{
npm: 'npm install @module-federation/bridge-vue3@latest',
yarn: 'yarn add @module-federation/bridge-vue3',
pnpm: 'pnpm add @module-federation/bridge-vue3@latest',
}}
/> Type Example Remote Host Parameters createRemoteAppComponent optionsloadertype: () => Promise<Module>Purpose: Used to load remote modules, e.g., loadRemote('remote1/export-app') or import('remote1/export-app')exporttype: stringPurpose: Used to specify module exportasyncComponentOptionstype: Omit<AsyncComponentOptions, 'loader'>Purpose: Parameters that will be passed to defineAsyncComponent, except for the loader parameterrootAttrstype: Record<string, unknown>Purpose: Attributes that will be bound to the root container where the remote Vue application will be mounted ReturnTypetype: VueComponentPurpose: Used to render remote module components createBridgeComponent bridgeInfotype: { rootComponent: VueComponent; appOptions?: (params: AddOptionsFnParams) => ({ router?: Router }) }Purpose: Used to pass the root componentReturnTypetype: () => { render: (info: RenderFnParams) => void; destroy: (info: { dom: HTMLElement}) => void; }
- [Angular CLI Setup](/practice/frameworks/angular/angular-cli.md): This guide explains how to integrate Module Federation with Angular CLI. The @angular-architects/module-federation plugin is used to assist with this integration.
- [Micro-frontends with Angular](/practice/frameworks/angular/angular-mfe.md)
- [Authentication with Auth0](/practice/frameworks/angular/auth0.md): This documentation outlines the process for sharing authentication states, such as the current user context, across micro-frontends within an application shell using Auth0 and Angular.
- [Server-Side Rendering](/practice/frameworks/angular/mf-ssr-angular.md): Historically, Module Federation was limited to Client-Side Rendering (CSR), primarily benefiting Single Page Applications (SPAs). However, the evolving web development landscape has increasingly favored Server-Side Rendering (SSR) for its myriad benefits.
- [Authentication with Okta](/practice/frameworks/angular/okta-auth.md)
- [Using Service Workers](/practice/frameworks/angular/service-workers-mf.md)
- [Splitting a Monolith](/practice/frameworks/angular/splitting-to-mf-part1.md)
- [Extending a Monolith](/practice/frameworks/angular/splitting-to-mf-part2.md): Welcome to the second part of our series on enhancing Angular applications using Module Federation (MF). In this guide, we'll delve into how to seamlessly incorporate MF into an existing plain Angular application.
- [Using Nx CLI for Angular](/practice/frameworks/angular/using-nx-for-angular.md): This guide explains how to integrate Module Federation for Angular projects using the Nx CLI.
- [Dynamic load provider](/practice/frameworks/modern/dynamic-remote.md): Modern.js provides Data Loader to help For data management, Data Loader is only executed on the server side and will not be executed repeatedly on the client side. This chapter will introduce how to use Data Loader to obtain producer information and load it dynamically.
- [Quick Start](/practice/frameworks/modern/index.md): :::tip Example Demo Modern.js SSR :::
- [Dynamic Remotes](/practice/frameworks/next/dynamic-remotes.md)
- [Working with Express.js](/practice/frameworks/next/express.md): If using express, hot server hot module reloading may not work after these steps Express has its own route stack, so reloading require cache will not be enough to reload the routes inside express. Trigger callback in revalidation add a global callback in _document.js to clear the Express route cache during revalidation, allowing updated routes to be served without server restarts.
- [Importing Components](/practice/frameworks/next/importing-components.md): Remote Modules can be imported in various ways. Lazy / Async import Default Exports Use React.lazy and React.Suspense :::danger Hydration Errors
Using next/dynamic to import remote modules will cause Hydration Errors
::: Named exports Named Exports require a mocked default be returned to React.lazy which expects only default exports. Eager / Sync import Eager imports work as well, but it is reccomneded to use dynamic imports when possible to avoid large upfront network transfors or requests Client side only In some cases, you may just want to load a remote module on the client. For example, if your remote does not provide a commonjs and browser build target. Node requires a remoteEntry in commonjs format, you cannot provide a browser designated remote to a Server.
- [Routing & Importing Pages](/practice/frameworks/next/importing-pages.md): Importing federated pages in Next.js required working within the constraints of how next builds.
- [Basic Example](/practice/frameworks/next/index.md): :::danger Project Deprecation
Support for Next.js is ending read more
::: :::tip Demo Reference
Check out the example project list here: Next.js SSR
:::
- [Presets](/practice/frameworks/next/presets.md)
- [](/practice/frameworks/overview.md)
- [Internationalization (i18n)](/practice/frameworks/react/i18n-react.md): :::tip Demo Reference
Check out the example project list here: React i18n
:::
- [Basic CRA with Rsbuild](/practice/frameworks/react/index.md): :::tip Demo Reference
Check out the example project list here: Rsbuild CRA
:::
- [Using Nx CLI for React](/practice/frameworks/react/using-nx-for-react.md): This guide explains how to integrate Module Federation for React projects using the Nx CLI.
- [Benefits of Module Federation in a Monorepo](/practice/monorepos/index.md): Module Federation is a powerful tool that allows you to share code between applications. It enables you to build applications that are more modular, maintainable, and scalable. In this guide, we will explore the benefits of using Module Federation in a monorepo. Polyrepos (multiple repositories) have long since been the de facto choice for developing micro-frontends, to combat organizational issues, however, they introduce more organizational challenges around code sharing, dependency management, versioning and team autonomy. Enabling team autonomy via Micro Frontends inadvertently pushed teams towards a polyrepo structure. Each team would have their own repository and would be responsible for maintaining their own codebase. This approach led to a lack of collaboration and a lack of transparency among other challenges. You can get all the benefits of Module Federation without the hassle of managing multiple repositories when you choose a monorepo, including some additional benefits around code sharing and dependency management.
This guide will help you understand the benefits of using Module Federation in a monorepo and how they address organizational challenges.
- [Nx and Module Federation](/practice/monorepos/nx-for-module-federation.md): Nx is a powerful open-source build system that works especially well with monorepos and comes with built-in support for Module Federation for Angular and React projects. If you haven't already read the benefits of using a monorepo for Module Federation, make sure to read Benefits of Module Federation in a Monorepo first.
- [Overview](/practice/overview.md): Module Federation, as a module sharing solution, aims to solve code reuse issues, optimize the build process, and enhance runtime performance. However, in practical project development, these functionalities alone are insufficient. It often needs to be combined with various frameworks to understand how to use Module Federation under different frameworks and how to integrate multiple functionalities from different frameworks. Additionally, it is necessary to consider the differing needs of various application scenarios, such as backend applications versus mobile application development scenarios.
This "Practical Guide" aims to address the above issues by providing a series of best practices for using Module Federation. The main content includes two parts: Bridge: For common business development scenarios: how to load application-level modules (with routing) and how to load modules across different frontend frameworks.Framework: Introduces the usage of Module Federation in different frameworks.
- [Data Prefetch](/practice/performance/prefetch.md): :::danger Deprecated This feature is no longer maintained and will be deprecated soon. We recommend using bridge-react - prefetch, which supports Rspack/Webpack and works in both SSR and CSR scenarios. :::

## Configuration

- [dev](/configure/dev.md): Type: boolean | PluginDevOptionsRequired: NoDefault value: trueUsage scenario: used to control Module Federation dev behavior The PluginDevOptions types are as follows:
- [dts](/configure/dts.md): Type: boolean | PluginDtsOptionsRequired: NoDefault value: trueUsage scenario: used to control <code>{props.brandName || props.name || 'Module Federation'}</code> generation/consumption type behavior After configuration, the producer will automatically generate a compressed type file @mf-types.zip (default name) during build, and the consumer will automatically pull the type file of remotes and decompress it to @mf-types (default name). The PluginDtsOptions types are as follows: generateTypes Type: boolean | DtsRemoteOptionsRequired: NoDefault value: trueUsage scenario: used to control Module Federation generation type behavior The DtsRemoteOptions types are as follows: When configuring generateTypes to true, the following configuration will be generated by default: extractRemoteTypes Type: booleanRequired: NoDefault value: undefinedUsage scenario: When the content of the producer exposes has its own remotes module that re-exports itself, then extractRemoteTypes: true can ensure that the consumer can normally obtain the module type of the producer exposesExample: [Nested type re-export](../guide/basic/type-prompt#Nested type re-export) Whether to extract the type of remotes. extractThirdParty Type: booleanRequired: NoDefault value: undefinedUsage scenario: When the content of the producer exposes contains a module containing antd, and the consumer does not have antd installed, then extractThirdParty: true can ensure that the consumer can normally obtain the module of the producer exposes typeExample: [Third-party package type extraction](../guide/basic/type-prompt#Third-party package type extraction) Whether to extract third-party package types. generateAPITypes Type: booleanRequired: NoDefault value: undefinedExample: Federation Runtime API type prompt Whether to generate the loadRemote type in Federation Runtime compileInChildProcess Type: booleanRequired: NoDefault value: undefined Whether generate types in child process abortOnError Type: booleanRequired: NoDefault value: false Whether to throw an error when a problem is encountered during type generation tsConfigPath Type: stringRequired: NoDefault value: path.join(process.cwd(),'./tsconfig.json') priority: dts.generateTypes.tsConfigPath > dts.tsConfigPath
tsconfig configuration file path outputDir Type: stringRequired: NoDefault value: undefined Custom base output directory for generated type assets. When this option is not set, Module Federation emits @mf-types.zip and
@mf-types.d.ts relative to the bundler output directory. If your remote entry
is emitted to a nested subdirectory such as production/remoteEntry.js, set
dts.generateTypes.outputDir to the same nested output directory so the type
artifacts are emitted alongside the entry file. This keeps the default inferred type URLs aligned with the remote entry path, so
consumers usually do not need remoteTypeUrls just because the remote entry is
served from a subdirectory. With the config above, the generated files are emitted to
dist/react/production/@mf-types.zip and
dist/react/production/@mf-types.d.ts. typesFolder Type: stringRequired: NoDefault value: '@mf-types' The name of the generated compression type file. For example, if typesFolder is set to custom, then the name of the generated compression type file is: custom.zip deleteTypesFolder Type: booleanRequired: No
-Default: true Whether to delete the generated type folder compilerInstance Type: 'tsc' | 'tsgo' | 'vue-tsc' | 'tspc' | stringRequired: NoDefault value: 'tsc' Instance of compiled type deleteTsConfig Type: booleanRequired: NoDefault value: true Whether to delete the temporary tsconfig configuration file. consumeTypes Type: boolean | DtsHostOptionsRequired: NoDefault value: trueUsage scenario: used to control Module Federation consumption (loading) type behavior The DtsHostOptions types are as follows: When configuring consumeTypes to true, the following configuration will be generated by default: consumeAPITypes Type: booleanRequired: NoDefault value: trueExample: Federation Runtime API type prompt Whether to generate the type of runtime loadRemote API maxRetries Type: numberRequired: NoDefault value: 3 Maximum number of retries for failed loading abortOnError Type: booleanRequired: NoDefault value: false Whether to throw an error when a problem is encountered during type loading typesFolder Type: stringRequired: NoDefault value: '@mf-types' Type storage directory after successful loading deleteTypesFolder Type: booleanRequired: NoDefault value: true Before loading type files, whether to delete the previously loaded typesFolder directory remoteTypesFolder Type: stringRequired: NoDefault value: '@mf-types' typesFolder corresponding to remotes directory configuration remoteTypeUrls Type: (() => Promise<RemoteTypeUrls>) | RemoteTypeUrlsRequired: NoDefault value:undefined Used for getting the address of the remote type file. Application scenarios: Only the runtime API is used to load the producer, and no build plugin is used. The MF type file address is informed by creating a module-federation.config.ts configuration file and setting this configuration. When remote is remoteEntry.js, the type file address usually directly replaces the js file with the corresponding type file, such as @mf-types.zip, but the actual uploaded type file address is not this, so you can tell MF the real type file address by setting this configuration. family Type: 4 | 6Required: NoDefault value: 4 Configure the IP version family that will be used for network operations. typesOnBuild Type: booleanRequired: NoDefault: false By default, Module Federation does not load type files in production ( process.env.NODE_ENV === 'production' ). To enable type loading in production builds, set typesOnBuild to true . tsConfigPath Type: stringRequired: NoDefault value: path.join(process.cwd(),'./tsconfig.json') tsconfig configuration file path cwd Type: stringRequired: NoDefault value: undefined The working directory to run the compiler displayErrorInTerminal Type: booleanRequired: NoDefault value: true Whether print error log in terminal
- [experiments](/configure/experiments.md): The experiments configuration enables advanced and experimental capabilities in the plugin.
- [exposes](/configure/exposes.md): Type: PluginExposesOptionsRequired: NoDefault value: undefinedUsage: Determines the modules and file entries exposed by <code>{props.brandName || props.name || 'Module Federation'}</code>. :::tip
A producer-specific parameter, setting exposes indicates that this is a producer. ::: After configuration, the exposed modules will be separated into a distinct chunk, and if there are any asynchronous chunks, they will be extracted into individual chunks as well (the specific extraction behavior depends on the chunk splitting rules). The PluginExposesOptions type is as follows: The exposeKey is essentially consistent with the Package Entry Points specification (except for not supporting regular expression matching). Example:
- [filename](/configure/filename.md): Type: stringRequired: NoDefault value: remoteEntry.jsUsage: Determines the filename of the generated remoteEntry.
- [getPublicPath](/configure/getpublicpath.md): Type: stringRequired: NoDefault value: undefinedEffective condition: only effective when exposes is setPurpose: Used to set a dynamic publicPath. The value must be a stringified function or a stringified return expression. When other consumers load this provider, the string in getPublicPath will be executed via new Function to obtain the return value, which will be used as the publicPath prefix for the module’s static assets.Function form: function(){ return window.cdn_prefix }Return form: return "https:" + window.navigator.cdn_host + "/resource/app/"Example: In the example below, getPublicPath is set. When other consumers load this provider, the string in getPublicPath will be executed using new Function to obtain the value, which will be used as the publicPath prefix for the module’s static assets. :::tip NOTE
getPublicPath must be a stringified function or a stringified return expression.
::: :::tip NOTE
If you're using the module federation webpack plugin and want to set a dynamic publicPath, you should set __webpack_public_path__ = window.cdn_prefix in the getPublicPath function body.
:::
- [implementation](/configure/implementation.md): Type: stringRequired: NoDefault value: undefined The implementation option is used to modify the actual bundler runtime version. It should be set to the path of @module-federation/runtime-tools. When working with Module Federation, the runtime is responsible for handling the loading and sharing of remote modules. By default, the bundler uses a specific version of the runtime that is compatible with its version. However, in some cases, you might need to use a different version of the runtime or a custom implementation. By specifying the implementation option, you can provide a path to the desired runtime implementation. This is particularly useful if you need to use features from a newer or older version of the runtime that are not available in the default version provided by the bundler. For example, if you want to use a specific version of @module-federation/runtime-tools, you can set the implementation option in your configuration file:
- [Configuration Overview](/configure/index.md): The current page lists all the configuration options for Module Federation. Please refer to the documentation for Build Plugins to understand how to use them.
- [injectTreeShakingUsedExports](/configure/injectTreeShakingUsedExports.md): Whether to inject the exports used by shared into the bundler runtime. Type: booleanRequired: NoDefault: undefined This option controls whether the actual used exports from shared modules are injected into the bundler runtime, enabling more precise dependency management and optimizations. If you are using mode: 'server-calc', it is recommended to set this option to false.
- [library](/configure/library.md): library configures the output library format of the Module Federation container, determining how the container is exposed to external consumers. Type: LibraryOptionsRequired: NoDefault: undefined
- [manifest](/configure/manifest.md): Type: boolean | PluginManifestOptionsDefault value: undefined Controls whether the plugin generates manifest artifacts and how they are produced. When enabled, the plugin emits  <code>{props.manifest || 'mf-manifest.json' }</code> and <code>{props.stats || 'mf-stats.json' }</code> (names can be customized via fileName) on every build so that other tools can consume them directly through processAssets or from the final build output. <code>{props.stats || 'mf-stats.json'}</code>: captures the full build statistics, including the assets for exposes/shared/remotes, metaData (plugin version, build info, remoteEntry, etc.), and any additional asset analysis. Ideal for debugging or merging stats across environments.<code>{props.manifest || 'mf-manifest.json'}</code>: a runtime-oriented manifest distilled from the stats. It keeps the stable structure that {props.brandName  || 'Module Federation'} consumers read when loading remote modules. The exposes/shared/remotes entries describe what is actually available to consumers. The PluginManifestOptions types are as follows:
- [name](/configure/name.md): Type: stringRequired: Yes Module Federation module name, the name must be unique. Module Federation uses the name for runtime data retrieval and global chunk storage variable references.
- [remotes](/configure/remotes.md): Type: PluginRemoteOptionsRequired: NoDefault: undefinedUsage: Used for consuming remote modules in Module Federation :::tip
A parameter unique to consumers. If remotes is set, it can be considered that this is a consumer. ::: The PluginRemoteOptions type is as follows: remoteAlias is the name actually used for reference by the consumer and can be configured as needed. For example, if remoteAlias is set to demo, then the consumption method would be ``.ModuleFederationInfo is composed of ModuleFederation name + @ + ModuleFederation entryModuleFederation name is the name set by the producerentry can be either mf-manifest.json or remoteEntry.jsWhen entry is mf-manifest.json, it has the following additional capabilities:Dynamic module type hintsResource preloadingChrome devtool debugging tool
- [remoteType](/configure/remotetype.md): remoteType specifies the external module type for remote containers, determining how the runtime loads remote entries. Type: ExternalsTypeRequired: NoDefault: 'script'
- [runtimePlugins](/configure/runtimeplugins.md): Type: string[] | Array<[string, Record<string, unknown>]>Required: NoDefault: undefined The runtimePlugins configuration is used to add additional plugins needed at runtime. The value can be: A string representing the path to the specific plugin (absolute/relative path or package name)An array where each element can be either a string or a tuple with [string path, object options] You can learn more about how to develop runtimePlugin details by visiting the Plugin System. Once set, runtime plugins will be automatically injected and used during the build process. Examples Basic usage:
To create a runtime plugin file, you can name it custom-runtime-plugin.ts: Then, apply this plugin in your build configuration: With options:
You can also provide options to runtime plugins by using a tuple format: The plugin can then access these options:
- [shareScope](/configure/shareScope.md): shareScope specifies which shared dependency pools (share scopes) a producer (remote) participates in. You can think of a share scope as a named shared-dependency pool: dependencies are only reused within the same scope. Type: string | string[]Required: NoDefault: 'default'
- [shareStrategy](/configure/shareStrategy.md): Type: 'version-first' | 'loaded-first'Required: NoDefault: 'version-first' (set by webpack plugin/bundler runtime) Control the loading strategy of shared dependencies: 'version-first': Version priority, ensuring that the highest version of shared dependencies is used. All remotes entry files will be automatically loaded during initialization to register shared dependencies and ensure version compatibility. This strategy is recommended when there are strict version requirements.'loaded-first': Prioritize reuse of already loaded shared dependencies. Remotes are loaded on-demand rather than during initialization. This strategy is recommended when you want to reuse loaded dependencies for performance. :::warning Offline Remote Considerations The 'version-first' strategy automatically loads remote entry files during application startup to initialize shared dependencies. If any remote is offline or unreachable, this will trigger the errorLoadRemote hook with lifecycle: 'beforeLoadShare' during startup. Without proper error handling, this can cause application initialization failures. The 'loaded-first' strategy defers remote loading until modules are actually requested, which means offline remotes only cause failures when those specific remotes are accessed, not during application startup. What happens with version-first and offline remotes: During initialization, remotes are loaded via initializeSharing()If remote manifest/entry is offline, module.getEntry() failserrorLoadRemote hook is called with lifecycle: 'beforeLoadShare'If no fallback is provided, the initialization may hang or fail Required error handling for version-first: For production applications with potential network issues, consider: Using 'loaded-first' strategy for better resilienceImplementing comprehensive error handling for 'beforeLoadShare' lifecycleAdding retry mechanisms via pluginsUsing proper error boundaries and fallback components See Error Load Remote Solutions for detailed offline handling strategies. :::
- [shared](/configure/shared.md): The shared configuration is used to share common dependencies between consumers and producers, reducing the runtime download volume and thus improving performance. shared allows you to configure rules for reusing dependency versions. You can learn more about the scenarios where shared is applicable and how to use shared through the FAQ. Type: PluginSharedOptionsRequired: NoDefault: undefined The PluginSharedOptions type is as follows: Example
- [treeShakingDir](/configure/treeShakingDir.md): The directory used to output tree-shaking shared fallback assets. Type: stringRequired: NoDefault: undefined When shared dependency tree shaking is enabled, {props.brandName || props.name || 'Module Federation'} will extract the exports of unused shared modules. This option specifies the output directory for those fallback assets.
- [treeShakingSharedExcludePlugins](/configure/treeShakingSharedExcludePlugins.md): Configures the plugin names to exclude during the shared dependency tree shaking/fallback process. Type: string[]Required: NoDefault: ['HtmlWebpackPlugin','HtmlRspackPlugin'] Allows users to specify a list of plugin names. These plugins will be ignored and will not participate in the shared dependency tree shaking/fallback process.
- [treeShakingSharedPlugins](/configure/treeShakingSharedPlugins.md): A list of plugin module paths used when building independent shared fallbacks. During the secondary tree-shaking build, each item will be require(p)-loaded and instantiated to participate in compilation. Type: string[]Required: NoDefault: undefined If shared.treeShaking.mode is set to 'server-calc', the deployment service will rebuild the shared dependencies that need tree shaking. In this process, only the shared dependencies are built, and the original project's build configuration is not loaded. If your project relies on special build configuration—for example, setting externals—you can package that configuration into an NPM package, then provide the plugin name and version in treeShakingSharedPlugins. This allows the plugin to participate in the second tree-shaking pass for shared modules. For example, suppose you provide a plugin my-build-plugin that sets externals: If you publish this plugin as version 0.0.2, you only need to specify its name and version in treeShakingSharedPlugins:

## Plugins

- [Plugin System](/plugin/dev/index.md): {props.brandName || props.name || 'Module Federation'} provides a lightweight runtime plugin system for implementing most of its features and allowing users to extend functionalities. Plugins developed by developers can modify the default behavior of <code>{props.brandName || props.name || 'Module Federation'}</code> and add various additional features, including but not limited to: Obtaining context informationRegistering lifecycle hooksModifying {props.brandName || props.name || 'Module Federation'} configurations...
- [Building a Custom Retry Plugin](/plugin/plugins/building-custom-retry-plugin.md): This guide shows how to create a custom retry plugin with advanced features like circuit breaker patterns, fallback components, and intelligent error handling for Module Federation applications.
- [Node Plugin](/plugin/plugins/index.md): Module Federation on the server-side enables many possibilities for backend architecture as well as enables server side rendering of apps.
- [Retry Plugin](/plugin/plugins/retry-plugin.md): Automatic retry for resource loading failures in Module Federation. Supports domain rotation, cache-busting, and custom callbacks.

## Showcase

- [Showcase](/showcase/index.md): Welcome to the Module Federation showcase page! Here, we present a collection of websites built using the Module Federation technology. If you have built a website using Module Federation and would like to share it with the community, we would greatly appreciate it. Simply reply in the GitHub discussion thread with a link to your website. We will regularly collect submissions and feature them on this page.

## Blog

- [Announcement of Release](/blog/announcement.md): April 26, 2024 Today, we are excited to announce the official release of Module Federation 2.0!
This new version is a collaborative effort between the ByteDance Web Infra team, the author of Module Federation, Zack Jackson
and several of our community members. Special thanks to @ilteoood, @patricklafrance and @crutch12.
Module Federation 2.0 addresses many issues from the previous version, building upon ByteDance's internal practices and the existing community ecosystem of Module Federation.
- [Error handling for remote module rendering in Module Federation.](/blog/error-load-remote.md)
- [Async Startup in Module Federation](/blog/hoisted-runtime.md): Sep 5, 2024 We're excited to announce a new experimental feature: experiments.asyncStartup = true. This release introduces asynchronous startup, enabling automatic async initialization for Module Federation entrypoints.
- [Overview](/blog/index.md): Find the latest posts and release announcements about Module Federation here.
- [{props.name || 'Module Federation'} on Node.js, Made Easy](/blog/node.md): {props.name || 'Module Federation'} supports Node.js out of the box. Whether you are consuming modules at runtime only, or integrating into a Webpack/Rspack build pipeline, it can be adopted with a relatively small amount of configuration. This document walks through common ways to use {props.name || 'Module Federation'} in Node.js.
- [MF 2.0 Stable Release: Balancing Developer Productivity and Extreme Performance](/blog/v2-stable-version.md): One year ago, we open-sourced Module Federation 2.0 (MF 2.0), and since then we have received a wealth of valuable feedback and suggestions from the community. We believe that a mature micro-frontend solution must not only improve collaborative development efficiency, but also provide a core engine that enables extreme performance. With this in mind, we have spent the past year deeply refining MF 2.0 and expanding its capabilities. Today, we are pleased to announce that MF 2.0 is now officially stable. The stable release delivers powerful performance optimizations, covers a broader range of deployment scenarios, and significantly improves the developer experience.