You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: apps/website-new/docs/en/configure/advanced-sharing.mdx
+11-8Lines changed: 11 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -83,7 +83,7 @@ new ModuleFederationPlugin({
83
83
});
84
84
```
85
85
86
-
## Enhanced Sharing Options: Layers and Filtering
86
+
## Layers
87
87
88
88
### `layer`
89
89
@@ -217,7 +217,8 @@ You can use both `layer` and `issuerLayer` in the same shared config.
217
217
218
218
This combination is powerful for creating highly specific sharing boundaries, ensuring that shared modules behave correctly and are isolated as needed within different parts of a complex, layered application.
-**`fallbackVersion?: string`**:\n - **Only used with `exclude.version`** when an `import` (local fallback) is specified.\n - Provides the version string of the local fallback module for the exclusion check, avoiding a dynamic lookup.\n - If this `fallbackVersion` satisfies the `exclude.version` range, the local fallback is excluded.
241
242
242
-
## Why Version Exclusion Matters
243
+
###Why Version Exclusion Matters
243
244
The version exclusion feature addresses several critical use cases in microfrontend architectures:
244
245
245
-
### Use Case 1: Preventing Problematic Dependency Versions
246
+
####Use Case 1: Preventing Problematic Dependency Versions
246
247
Sometimes specific versions of dependencies have known bugs or incompatibilities. With version exclusion, you can:
247
248
```ts
248
249
shared: {
@@ -255,7 +256,7 @@ shared: {
255
256
```
256
257
This ensures that even if a federated module tries to provide version 2.3.0, it will be ignored, preventing potential application failures.
257
258
258
-
### Use Case 2: Controlled Migration Paths
259
+
####Use Case 2: Controlled Migration Paths
259
260
When gradually migrating to newer versions across multiple teams:
260
261
```ts
261
262
shared: {
@@ -268,7 +269,7 @@ shared: {
268
269
```
269
270
This configuration prevents sharing of very old versions while still allowing a controlled range of compatible versions.
270
271
271
-
### Use Case 3: Performance Optimization with `fallbackVersion`
272
+
####Use Case 3: Performance Optimization with `fallbackVersion`
272
273
The `fallbackVersion` property provides a performance optimization that avoids filesystem lookups:
273
274
```ts
274
275
shared: {
@@ -284,7 +285,7 @@ shared: {
284
285
```
285
286
By explicitly specifying `fallbackVersion`, the system can immediately determine whether to use the fallback without having to parse package.json files, which improves build performance.
286
287
287
-
### Use Case 4: Preventing Loading of Incompatible Singletons
288
+
####Use Case 4: Preventing Loading of Incompatible Singletons
288
289
For singleton libraries like React, loading incompatible versions can cause runtime errors:
289
290
```ts
290
291
shared: {
@@ -343,7 +344,9 @@ In this Next.js-style example:
343
344
-`react` is configured differently for `rsc` (React Server Components) layer and `client` layer. Each uses its own `layer`, `issuerLayer`, and `shareScope` to ensure proper isolation and version control.
344
345
-`next/` prefix sharing is applied to the `client` layer, excluding certain subpaths that might not be needed or could cause issues on the client.
345
346
346
-
## Node Modules Path Resolution
347
+
## nodeModulesReconstructedLookup
348
+
349
+
This section covers the nodeModulesReconstructedLookup experiment, which helps with sharing modules that use relative imports internally.
347
350
348
351
Module Federation offers an experimental feature `nodeModulesReconstructedLookup` to solve a common issue with sharing modules that use relative imports internally.
0 commit comments