Support Shared Tree Shaking

[2heal1]

How It Works

Shared dependency tree shaking can be summarized as a closed-loop pipeline: “collect used exports → compute a global set → secondary build → runtime on-demand loading”.

The problem it addresses is: in Module Federation shared-dependency scenarios, you typically want both high reuse (less duplicate downloading) and smaller shared bundles (less unused code). By persisting “which exports are actually used” (via usedExports) as build metadata and driving a secondary build from it, the shared dependency can stay reusable while being as small as possible.

Below is the process broken down into 4 stages.

Diagram

Stage 1: Build assets

In this stage you build your apps as usual, and for shared dependencies with tree shaking enabled you produce:

• Full bundle: a complete shared dependency bundle without tree shaking, used for fallback and compatibility.
• Tree-shaken bundle: a smaller version produced from static analysis.
• Metadata: records which exports were actually used in the tree-shaken bundle (usedExports), e.g. Badge, Progress in the diagram.

Stage 2: Calculate the dependency set

The goal of this stage is to determine: “within the current system scope, which exports of a given shared dependency must be kept?”

In the diagram, Consumer A depends on Provider. Using the manifest/stats generated in Stage 1, you can infer the set of exports it needs from the shared dependency (e.g. antd): Avatar, Badge, Calendar, QRCode, Modal, Progress, etc.

Depending on whether you have a centralized Deploy Server, there are typically two approaches:

1. Server-assisted (server-calc): during CI/CD or release, a centralized service aggregates usedExports from all apps for the same shared dependency, computes a global “minimum union”, and generates an optimized artifact that all consumers can reuse.
2. Runtime inference (runtime-infer): without a centralized service, apps try to reuse an already-loaded tree-shaken shared bundle at runtime; if it doesn’t satisfy what the current page needs, fall back to the full shared bundle to ensure correctness.

Stage 3: Secondary build (shared dependency)

In this stage you run an isolated secondary build for the shared dependency based on the export set computed in Stage 2, producing a shared bundle that is smaller and still reusable.

• With a Deploy Server, the Deploy Server typically triggers the secondary build via a Build Server during release, passing in the usedExports to keep (the Stage 2 result).
• Without a Deploy Server, you need to manually specify usedExports in your local MF config. In the Consumer A example, the “missing” exports to include are the purple-highlighted modules: Calendar, QRCode.

Stage 4: Runtime on-demand loading

This stage happens at runtime. The consumer app decides which shared resource to load based on whether tree shaking is enabled and whether it has the guidance metadata for the secondary artifact (e.g. related fields in Snapshot/manifest):

• If the secondary artifact is available: load the tree-shaken shared bundle (smaller).
• If not available or conditions aren’t met: fall back to the full shared bundle (safer).

[giavinh79]

Looking forward to this, wondering if there's an expected release date? Thanks for your work!

[2heal1]

Next week Webpack version will be release first , and one week later(I guess), rspack coming !