FlorianRappl
commented
10 months ago Quick update on the current design: Right now the idea is that the orchestrator (i.e., Piral, or more precisely, the loading coming from piral-base) is supporting Module Federation out of the box. This way pilets can be loaded also using a mf spec, which would have the advantage that there is a clear path towards going into mf.
How? Well as schemaVersion you'd just select mf. If a bundler does not support that schema version - the bundler will just throw and refuse to work. This is already the case, e.g., for v1 schema with piral-cli-esbuild. Now using piral-cli-esbuild (as an example) with mf would throw, too.
On the other hand, support for such a pilet in an app shell behaves the same as with other specs. If the app shell supports it, then the pilet will be loaded. Otherwise, it would be discarded. Right now, the thinking is that from 1.4.0 on the app shell will just support it.
What will be possible with this mechanism? All that was initially planned. So you can add more things to be shared from your Module Federated pilets, as well as re-use things you brought in via the app shell or some (non-MF) pilet to a pilet that uses Module Federation. It's just a very smooth process.
New Feature Proposal
For more information, see the
CONTRIBUTINGguide.Description
The orchestration engine of Piral can actually support multiple / different mechanisms for dependency resolution or micro frontend loading. Ideally, other mechanisms can be just added into the app shell directly, such that loading a micro frontend using module federation would be immediately supported.
Background
In a Webpack-only (or supported bundlers) world Module Federation plays an important role. Some things that are right now triggered by the Piral CLI are supported directly in Webpack (et al) via Module Federation. Therefore, being in the Module Federation realm would not only simplify Piral, but also add other benefits such as a widened ecosystem.
Right now the idea is not to replace System.js. Actually, the anticipated integration would add Module Federation on top of System.js - making the two profit from each other. This also makes sense as it remains backward compatible, while allowing new modules / types of assets to be resolved.
Discussion
Should this be opt-in or just implicitly used when Webpack 5 is the bundler? Via what mechanism? I imagine that having a special flag in the "piral.json" would be most appropriate. This flag would be transported to the bundler plugin and if that plugin supports module federation it would activate it. Otherwise, a warning would be printed (or not - that actually depends if the CLI recognizes that the bundler plugin does not know how to handle this flag / how we implement the handling of this flag).
The other question is for pilets; should pilets recognize that the app shell has Module Federation active? What if this changes over time? Can there be a fallback? And what if the pilet should support multiple app shells, but not all of them opt-in to Module Federation?