paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 28 Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse Source 
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
This commit is contained in:
Patrik Oldsberg
2026-02-12 23:20:05 +01:00
committed by GitHub
parent 3fdda3384e
commit 94e05532be
1 changed files with 2 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/frontend-system/building-apps/07-module-federation.md
+2 -6
View File
@@ -21,16 +21,12 @@ This guide explains how to configure and build both module federation hosts and
In module federation terminology:
- **Host**: The main frontend application that loads and consumes remote modules. In Backstage, this is your app package (typically `packages/app-next`).
- **Host**: The main frontend application that loads and consumes remote modules. In Backstage, this is your app package (typically `packages/app`).
- **Remote**: A separately built module that can be loaded by the host at runtime. In Backstage, these are typically plugin packages built as module federation remotes.
### Shared Dependencies
A critical aspect of module federation is **shared dependencies**. When a host loads remote modules, both need to share common dependencies (like React, React Router, Material-UI) to:
- Avoid loading the same dependency multiple times
- Ensure singleton dependencies (like React) only have one instance
- Enable context sharing between host and remotes
A critical aspect of module federation is **shared dependencies**. When a host loads remote modules, both need to share common dependencies (like React, React Router, Material-UI) in order to ensure singleton dependencies only have one instance.
Backstage provides a list of default shared dependencies for common packages like React, React Router, and Material-UI. At build-time the `version` field is automatically resolved from your `package.json` files.