Bit <> Module federation integration roadmap

[GiladShoham]

Module fedration is becoming a very popular method to app composition in runtime. In the last couple of months there's been a growing demand for MF native support in Bit.

This discussion lists the goals for this integration and outlines it's roadmap and progress.

Goals

Adding MF support for Bit will improve two main aspects of Bit:

Faster dev-experience

Bit uses Webpack to create an bundle, adds it as an artifact to your component, and uses it in several cases. With Module Federation Bit will split the single bundle to several modules. This has several benefits:

• Commands that use bundling/webpack will be significantly faster (start, build and tag).
• Workspace/Scope UI rendering will be quicker (mainly for overview and compositions tabs, and the gallery page)
• Less storage requirements for remote scopes and reduce network traffic for export.

Module Federation for component consumers

Consuming components as Federated Modules by configuring a Bit Scope as remote in the consumer's Webpack config.

An interesting "side-effect" for MF be available for components is the fact you get versioning for modules "out of the box".

This will be extended so you can determine additional publishing targets for federated modules (CDN for example).

Roadmap

The implementation is split to several stages. They are all listed here, but their order may change.

Stage 1 - Expose components as federated modules and optimize Bit performance

The implementation details of this phase are described under this issue - #4338

Stage 2 - Consume components by other components via MF

• Support detecting MF dependencies between components with teambit.workspace/dependency-resolver.
• Advanced handling of dependency detection/configuration/resolution via teambit.workspace/dependency-resolver.

Stage 3 - Mark versions as the MF stable versions on a Scope

This is about providing a way for the component author to mark the specific version as the stable version, so other consumers will be able to refer to this component as stable and always get the current stable version.

This will be available for bit import and bit install.

Stage 4 - Additional special tags to versions on a scope

The ability to mark any version with any tag you want. For example you can mark a version as "next" so others can configure MF remote to point to the @next version.

This will be available for bit import and bit install.

Stage 5 - auto adding fallback to npm package when consumed by the component

Ability to add syntax/API for consumer to fallback from using federated module as a consuming method to consuming it as a package.
When a component consumes another component via MF, this is about adding a special compilation part that will add to the component dist file a check if the MF module is available (for example server might be down), and if not will fall back to import it via the npm package.

Stage 6 - Smart "latest-stable" tag by the consuming component

The ability to ask for the remote for the latest stable for me as a specific consumer (component only). This is done by pointing the remote with a special tag (name TBD). Send the request to the server along with the component that asks for this as a context.
So for example, if a card asks for the "my-stable" version of a button he can get v2.0.0 but at the same time, if a button group asks for "my-stable" he will get v3.0.0. this happens if the server sees that v3.0.0 of the button is breaking the tests of the card, but not the tests of the button group.

This is an experimental initiative which we are likely to iterate a lot about.

[tysonrm]

I assume capsule test support is available like any Bit component. Stage 5 is significant. This is excellent, Gilad!

[itaymendel]

you can use module federation with bit - https://bit.cloud/frontend/module-federation