# Module federation > Module Federation is a concept that allows developers to share code and resources across multiple JavaScript applications ## AI - [AI Quick Start](/ai/index.md) - [Skills](/ai/skill.md): Module Federation now exposes one unified mf skill. You do not need to pick from a long list of separate skills, and you do not need to read the docs first and then translate them back to your agent. The simpler approach is to install this one skill and let the agent decide whether it should read docs, inspect config, or troubleshoot a problem. When a problem exists only in the live page runtime, the skill uses the Divebell MF Extension for structured Remote, Shared, Bridge, and module performance evidence. The browser is only the entry point and loading trigger. Divebell is installed on the agent machine, not in the application. If you have not read it yet, start with AI Quick Start. ## Guide - [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 - [Quick Start Guide](/guide/start/quick-start.md): 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. - [Glossary of Terms](/guide/start/glossary.md) - [Command Line Tool](/guide/basic/cli.md): {props.name || 'Module Federation'} provides a lightweight command-line tool {props.cmd || 'mf'}, shipped by {props.cmdTool || '@module-federation/enhanced'}. - [Style Isolation](/guide/basic/css-isolate.md): In Module Federation, the host and remote applications run on the same page and share a single global CSS scope, so styles from one side can easily leak into another and cause unintended "style pollution". Module Federation does not ship built-in style isolation (see the FAQ below for the reasoning), so producers should pick the strategy that fits their scenario. - [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. {props.pkgName || '@module-federation/enhanced'} has type hinting enabled by default. This article will introduce several common usage scenarios and their specific configurations. - [Manifest and Snapshot](/guide/basic/manifest-snapshot.md): mf-manifest.json is a runtime manifest generated by a producer after build. It describes which modules the producer exposes, where the remote entry is, which assets those modules need, which shared dependencies are available, and where the type files are. Snapshot is a condensed and pre-resolved result of Manifest information; the runtime can request Manifest and generate Snapshot on demand. If you have a deployment service, it can also generate Snapshot ahead of time and deliver it to the consumer, so the consumer can get the remote entry and preloadable assets directly. This document only explains the concepts and where they are used. For configuration, see manifest configuration. For complete fields, see mf-manifest.json fields. - [Runtime Access](/guide/runtime/index.md): 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. - [Runtime API](/guide/runtime/runtime-api.md): MF runtime APIs are built around the ModuleFederation instance. The default instance is usually created automatically by the build plugin, so you do not need to pass an instance explicitly when calling runtime APIs — they automatically apply to the default instance in the runtime. - [Runtime Plugins](/guide/runtime/runtime-plugins.md): Runtime plugins let you change runtime behavior without changing the core runtime itself. Use them when you need to: rewrite remote URLs at runtimecustomize manifest requestspatch script loadingoverride shared resolutionadd recovery or fallback behaviorintroduce new remote loading behavior If you only need to register a plugin path in build config, see runtimePlugins. If you need the full hook list, see Runtime Hooks. - [Runtime Hooks](/guide/runtime/runtime-hooks.md): The Module Federation runtime exposes hooks at key stages — loading remote modules, initializing containers, registering and resolving shared dependencies, and more. They are useful for diagnostics and tracing, error fallbacks, rewriting shared dependencies, customizing resource loading, and similar scenarios. - [Bridge Overview](/guide/bridge/overview.md): Bridge is a cross-framework application-level module loading and integration solution provided by Module Federation. It's not just a component loader, but a complete lifecycle management system specifically designed for handling "application-level modules." The core problem Bridge solves is: how to enable complete applications developed with different frontend frameworks to be dynamically loaded, rendered, and integrated as modules by other applications, while maintaining their respective technology stack independence and business integrity. Unlike traditional component-level sharing, Bridge handles complete application modules that include routing systems and business logic. Through Bridge, you can: Cross-framework Integration: Load Vue applications in React applications, load React applications in Vue applications, achieving true technology-agnostic integrationApplication-level Modularity: Export and consume complete applications (including routing and business logic) as modulesComponent-level Lazy Loading: Support fine-grained component-level loading for on-demand loading and performance optimizationRouting System Collaboration: Support complex nested routing scenarios, ensuring seamless collaboration between host and remote application routingLifecycle Management: Automatically handle mounting, unmounting, and updating of remote applications, ensuring proper resource managementApplication Isolation: Ensure styles, scripts, and contexts between different applications are isolated from each other to avoid conflictsProgressive Migration: Support gradual splitting of monolithic applications into micro-frontend architectures, reducing migration risks These capabilities make Bridge the core infrastructure for building modern, scalable micro-frontend architectures. - [React Bridge Overview](/guide/bridge/react/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. - [Export Applications](/guide/bridge/react/export-app.md): This chapter will introduce how to use createBridgeComponent to export your React application as a module that can be loaded remotely. - [Loading Applications](/guide/bridge/react/load-app.md): This chapter introduces how to use createRemoteAppComponent to load and integrate remote React applications in a host application. - [Lazy Load and Prefetch Components](/guide/bridge/react/load-component.md): This chapter introduces how to use createLazyComponent to load remote React components on demand in a host application. createLazyComponent is a higher-level loading API for React component scenarios. Compared with directly loading a module and wiring up React.lazy, Suspense, and error boundaries yourself, it builds those pieces into the API and additionally provides: Declarative loading and fallback: no need to manually wrap React.Suspense and error boundariesData prefetching: use prefetch to start dependency requests before the component loads, avoiding request waterfalls where data is requested only after the component is readySSR control: precisely control whether remote components render on the server, helping avoid CSS flickering issues - [Data Fetching](/guide/data/data-fetch.md): Remote modules typically want to handle data fetching on their own: the consumer is only responsible for loading and rendering, without having to know what data the remote depends on, and without each consumer reimplementing the same fetching logic. In CSR scenarios, a remote can simply call useEffect inside the component to fire the request. In SSR scenarios, however, useEffect does not run on the server, so the remote cannot fetch data on the server before rendering. Mainstream SSR frameworks (Next.js, Remix, Modern.js, etc.) usually provide route-level data prefetching: when a route matches, a data-loading function runs first, and its data is injected into the matching route component. But this mechanism depends on each framework's own router, and modules exposed by {props.name || 'Module Federation'} do not live in the host's route tree, so this cannot be reused directly. To solve this, {props.name || 'Module Federation'} provides component-level data fetching capabilities, so developers can fetch data and render components in SSR scenarios. - [Data Caching](/guide/data/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 scenarios such as Client-Side Rendering (CSR) and Server-Side Rendering (SSR). - [Data Prefetch](/guide/data/data-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)} - [Optimize Runtime Size](/guide/advanced/runtime-size-optimization.md): The {props.name || 'Module Federation'} runtime includes remote consumption, shared dependencies, and Manifest / Snapshot capabilities by default. This covers most use cases out of the box, but code for unused capabilities can still be included in the final output. Use experiments.optimization to remove capabilities that a build will definitely not use and reduce its runtime size. - [Shared Tree Shaking](/guide/advanced/shared-tree-shaking.md): When using { props.name || 'Module Federation' }, we often share common dependencies (such as antd, React, etc.) through the shared configuration to reduce duplicate bundling and keep dependency versions consistent across applications. However, the classic shared mechanism has a downside: it always provides the full dependency bundle, even if your application only uses a small portion of it (for example, only the Button component from antd). This can lead to: Large build artifacts: unnecessary code is bundled, increasing the final output size.Runtime overhead: the browser downloads and executes more JavaScript than needed, slowing down page load and render. Shared Tree Shaking is designed to solve this. It analyzes your code, precisely identifies which exports are actually used, and bundles only that subset. As a result, your application can consume an optimized, smaller shared dependency. - [Shared Dependency Isolation: Multiple Share Scopes](/guide/advanced/multiple-shared-scope.md): In {props.name || 'Module Federation'}, shared dependencies are registered into the default Share Scope by default. A single Scope is often not enough when: You want to isolate part of your shared dependencies from the default pool (for example, running two React ecosystems side-by-side, gradual upgrades, or domain isolation in micro-frontends).You want the same package to use different versions or strategies in different domains, while still being shared within each domain (singleton/reuse still works within a domain). The key idea of multiple Share Scopes is: move shared dependency registration and resolution into different namespaces (Scopes), so you can isolate shared pools and layer policies. - [Manifest Field Reference](/guide/advanced/manifest-fields.md): mf-manifest.json is generated when manifest is enabled. It is a runtime-oriented manifest distilled from mf-stats.json, keeping a stable, consumer-friendly shape. - [Stats Field Reference](/guide/advanced/stats-fields.md): mf-stats.json is generated when manifest is enabled. It contains full build statistics, including exposes/shared/remotes assets, metaData (build info, remoteEntry, etc.), and asset analysis results. Use this document to understand every field in mf-stats.json, which is helpful for debugging and analysis. - [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: - [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. For example: how to verify the effect of modules in actual projects during development, whether a producer's dependencies are reused with the host environment, which modules are loaded on the current page, and what the dependency relationships and data flow between modules look like. Chrome Devtool provides the following capabilities: Supports proxying remote modules from an online page to a local one.Switch online remote module versions for quick functional verification.Support viewing module dependency information.Support filtering specified module dependency information.Support Loading Trace for remote, shared, component-ready signals, and failure reports. - [Troubleshoot Runtime Issues](/guide/debug/divebell.md): Diagnosing Module Federation runtime problems is complex. Remote resolution, Shared version selection, Bridge lifecycle, and module performance evidence exist only in the live page runtime. Source code or Console output alone rarely reconstructs the complete chain. We built the Divebell MF Extension on top of the MF runtime and observability capabilities. It identifies MF instances, traces Remote, Shared, and Bridge loading, and analyzes the relationship between module loading, resource requests, and page paint timing. - [Global variables](/guide/debug/variables.md): In {props.name || 'Module Federation'}, the main global variables are __FEDERATION__, {props.shareVar || 'SHARE'} and {props.instanceVar || 'INSTANCES'}. They record the module federation info, shared module info, and instance info of the current application, and help us understand and debug the runtime behavior of module federation. - [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...): 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. - [Runtime](/guide/troubleshooting/runtime.md): This page collects runtime-related error codes and common troubleshooting guidance. - [Build](/guide/troubleshooting/build.md): This page collects build-time 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. - [NPM Packages](/guide/start/npm-packages.md): This document showcases all npm package information maintained by the Module Federation team. ## Integrations - [Integrations](/integrations/index.md): Module Federation is powered by MF Runtime. Most projects should use a build plugin. It lets you import remote modules like npm packages and provides engineering capabilities such as type hints. If your project needs to expose modules for other applications to consume, you must use a build plugin. If you do not want to change your build setup and only need to load remote modules at runtime, you can use Runtime directly. If you are not sure which package to install, start with your project type: You can also use Runtime only to load remote modules. Different project types import Runtime from different entries. Continue with Runtime Installation to learn how to choose the correct Runtime entry. - [Rsbuild](/integrations/build-tool/rsbuild.md): Help users quickly build Module Federation products in Rsbuild App. - [Rslib](/integrations/build-tool/rslib.md): Rslib can use @module-federation/rsbuild-plugin to build Module Federation producers. It is a good fit when a component library, business module, or SSR producer needs to be published as an independent artifact for other apps to consume. - [Rstest](/integrations/build-tool/rstest.md): @module-federation/rstest enables Module Federation inside Rstest test builds. Use it when your tests should load real federated remotes instead of replacing the federation boundary with mocks. - [Vite](/integrations/build-tool/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. roadmap 🗓️Consuming remote modules will have hot update capabilities.nuxt ssr - [Rspack](/integrations/bundler/rspack.md): Capable of building modules that meet the {props.brandName || props.name || 'Module Federation'} loading specifications.Can consume modules that adhere to the {props.brandName || props.name || 'Module Federation'} 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} - [Webpack](/integrations/bundler/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} - [Metro](/integrations/bundler/metro.md): Metro Module Federation brings the power of distributed architecture to React Native mobile development. - [Rspress](/integrations/documentation/rspress.md): Helps users build and consume {props.brandName || props.name || 'Module Federation'} products in Rspress. - [Modern.js Integration Overview](/integrations/framework/modernjs/index.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 both @module-federation/modern-js-v3 and @module-federation/modern-js to help users use Module Federation in Modern.js. We recommend upgrading to Modern.js v3 and using @module-federation/modern-js-v3 first. - [Quick Start](/integrations/framework/modernjs/quick-start.md): This chapter explains how to use the Module Federation plugin in Modern.js and provides a simple example that demonstrates how to create provider and consumer applications. - [Dynamic load provider](/integrations/framework/modernjs/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. - [Next.js Integration Overview](/integrations/framework/nextjs/index.md): This plugin enables Module Federation on Next.js. - [Basic Example](/integrations/framework/nextjs/basic-example.md) - [Dynamic Remotes](/integrations/framework/nextjs/dynamic-remotes.md) - [Importing Components](/integrations/framework/nextjs/importing-components.md): Remote Modules can be imported in various ways. Lazy / Async import Default Exports Use React.lazy and React.Suspense 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](/integrations/framework/nextjs/importing-pages.md): Importing federated pages in Next.js required working within the constraints of how next builds. - [Working with Express.js](/integrations/framework/nextjs/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. - [Presets](/integrations/framework/nextjs/presets.md) - [Angular Integration Overview](/integrations/framework/angular/index.md): When integrating Module Federation into an Angular app, choose the guide based on the build setup used by your project. Angular integrations commonly depend on Angular CLI, a custom Webpack builder, or Nx. Before choosing a guide, confirm your current build setup and whether SSR is required. If you only need the shared Module Federation configuration concepts, see Configuration for name, remotes, exposes, and shared. - [Angular CLI Setup](/integrations/framework/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. - [Using Nx CLI for Angular](/integrations/framework/angular/using-nx-for-angular.md): This guide explains how to integrate Module Federation for Angular projects using the Nx CLI. - [Micro-frontends with Angular](/integrations/framework/angular/angular-mfe.md) - [Server-Side Rendering](/integrations/framework/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. - [Using Service Workers](/integrations/framework/angular/service-workers-mf.md) - [Authentication with Auth0](/integrations/framework/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. - [Authentication with Okta](/integrations/framework/angular/okta-auth.md) - [Splitting a Monolith](/integrations/framework/angular/splitting-to-mf-part1.md) - [Extending a Monolith](/integrations/framework/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. - [Benefits of Module Federation in a Monorepo](/integrations/framework/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](/integrations/framework/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. - [Practice](/integrations/practice/index.md): This section collects framework and scenario-specific practice guides. Choose the integration for your build tool, framework, or Runtime usage in the Integrations overview first, then come back here for matching practice guides. - [React Practice](/integrations/practice/react/index.md): React apps do not use one fixed React-specific Module Federation plugin. Choose the integration based on the bundler used by your project first, then use these React scenario guides. If you need to load remote React components, continue with Bridge. If remote components need data fetching, data cache, or prefetch, continue with Data Management. - [Basic CRA with Rsbuild](/integrations/practice/react/rsbuild-cra.md) - [Internationalization (i18n)](/integrations/practice/react/i18n-react.md) - [Using Nx CLI for React](/integrations/practice/react/using-nx-for-react.md): This guide explains how to integrate Module Federation for React projects using the Nx CLI. - [Vue Bridge (for Vue v3)](/integrations/practice/vue.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. ## Configuration - [Configuration Overview](/configure/index.md): This page lists all configuration options for Module Federation. For package installation and plugin setup in different project types, see Integrations. - [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. - [filename](/configure/filename.md): Type: stringRequired: NoDefault value: remoteEntry.jsUsage: Determines the filename of the generated remoteEntry. - [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 - [remotes](/configure/remotes.md): Type: PluginRemoteOptionsRequired: NoDefault: undefinedUsage: Used for consuming producer modules with {props.brandName || props.name || 'Module Federation'} 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' - [shareScope](/configure/shareScope.md): shareScope specifies which shared dependency pools (Share Scope) a producer 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' - [exposes](/configure/exposes.md): Type: PluginExposesOptionsRequired: NoDefault value: undefinedUsage: Determines the modules and file entries exposed by {props.brandName || props.name || 'Module Federation'}. 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 usage: - [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: - [runtimePlugins](/configure/runtimeplugins.md): Type: string[] | Array<[string, Record]>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] For a task-oriented guide to choosing Hooks and building plugins, see Runtime Plugins. For the full Hook reference, see Runtime Hooks. For lower-level plugin authoring details, see the Plugin System. Once set, runtime plugins will be automatically injected and used during the build process. 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: - [getPublicPath](/configure/getpublicpath.md): Type: stringRequired: NoDefault value: undefinedEffective condition: only effective when exposes is set 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. For example, if your deployed project receives a dynamic cdn_prefix, you can configure it as: Function form: function(){ return window.cdn_prefix }Return form: return "https:" + window.navigator.cdn_host + "/resource/app/" 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. - [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: - [dts](/configure/dts.md): Type: boolean | PluginDtsOptionsRequired: NoDefault value: trueUsage scenario: used to control {props.brandName || props.name || 'Module Federation'} 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: - [dev](/configure/dev.md): Type: boolean | PluginDevOptionsRequired: NoDefault value: trueUsage scenario: used to control Module Federation dev behavior The PluginDevOptions types are as follows: - [manifest](/configure/manifest.md): Type: boolean | PluginManifestOptionsRequired: NoDefault value: undefined Controls whether the plugin generates manifest artifacts and how they are produced. When enabled, the plugin emits {props.manifest || 'mf-manifest.json' } and {props.stats || 'mf-stats.json' } (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. {props.stats || 'mf-stats.json'}: 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, see field references: {props.stats || 'mf-stats.json'}.{props.manifest || 'mf-manifest.json'}: 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, see field references: {props.manifest || 'mf-manifest.json'}. The PluginManifestOptions types are as follows: - [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. - [experiments](/configure/experiments.md): The experiments configuration enables advanced and experimental capabilities in the plugin. - [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. - [treeShakingDir](/configure/treeShakingDir.md): When the shared dependency Tree Shaking feature 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. Type: stringRequired: NoDefault: undefined - [treeShakingSharedExcludePlugins](/configure/treeShakingSharedExcludePlugins.md): Configures the plugin names to exclude during the shared dependency tree shaking/fallback process. These plugins will be ignored and will not participate in the shared dependency tree shaking/fallback process. Type: string[]Required: NoDefault: ['HtmlWebpackPlugin','HtmlRspackPlugin'] - [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 the original project depends on special build configuration (for example externals), you can wrap that configuration into an NPM plugin and publish it, then list the package name in treeShakingSharedPlugins. The secondary Tree Shaking pass will automatically require and instantiate these plugins so that the shared module build inherits the original configuration. For example, suppose you provide a plugin my-build-plugin that sets externals: Once you publish this plugin to npm, simply list its package name 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 {props.brandName || props.name || 'Module Federation'} and add various additional features, including but not limited to: Obtaining context informationRegistering lifecycle hooksModifying {props.brandName || props.name || 'Module Federation'} configurations... - [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. - [Observability Plugin](/plugin/plugins/observability-plugin.md): Observe Module Federation loading, collect runtime and build reports, and give humans or AI agents enough facts to debug failures. - [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. ## 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 - [Overview](/blog/index.md): Find the latest posts and release announcements about Module Federation here. - [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. - [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. - [Error handling for remote module rendering in Module Federation.](/blog/error-load-remote.md) - [{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. ## Playground - [Module federation](/playground/index.md)