A versioned shell contract catches micro frontend mismatches at load time

The shell and a remote are built at different times, by different pipelines, possibly weeks apart, and the shell first meets the remote's code when it loads it at runtime ^[3]. No build step ever compiles both halves together ^[3]. All three failure modes in the post start from that gap ^[4].

The author is precise about what Module Federation covers. "The config is what makes loading possible. It says nothing about what is safe to load," the author wrote ^[7]. By the post's account, adding the plugin and naming exposes and remotes takes an afternoon ^[2].

The team's fix puts a check at the one point that sees both sides: the moment before mount. As the post describes it:

1. Each remote declares the props of its exposed module, the shape of the events it emits, and the range of shared dependencies it was built against ^[5]. 2. The shell checks that range before it mounts anything ^[6]. 3. A remote outside the range is refused, and the shell renders a defined fallback in its place ^[6]. 4. The failure is reported at load, in one place, with a message naming the remote and the expected range ^[8].

This is good engineering. It treats a remote as input from another team's pipeline and validates it at the boundary ^[5][6]. The alternative is a component that throws halfway through a user's session and turns up as a broken screen someone reports two days later ^[6][8]. The post does not include the declaration format or the checking code. The text says the shell checks the dependency range, so it is not clear whether prop and event shapes are also verified at runtime ^[6].

The author wants the failure behaviour chosen in advance, whether that is a shell fallback, an error boundary or a feature flag ^[17]. "The default is a blank rectangle, and the default is the one you get if you do not choose," the author wrote ^[14].

The shared list is where duplicated libraries come from. In this setup React and the design system are declared shared with explicit ranges ^[9]. The author's rule is to keep that list short, because every shared dependency is a coupling that has to be versioned. A date library probably does not belong on it ^[10].

The 40% figure describes one frontend. The release cycle came down by about that much, and the author attributes most of it to waiting that disappeared, with build time a small part ^[11]. Before the split, every team waited for the slowest team in a single release ^[1]. After it, a team ships when its remote satisfies the contract ^[15]. For the number to carry over to another codebase, its releases have to be gated on several teams in the same way ^[1][11]. The author says a frontend owned by one team gets the coordination cost of a distributed system and keeps the release cadence of a monolith ^[13]. Seams should follow ownership, and smaller bundles are available from plain code splitting ^[12].

I think the ordering advice is the part that carries over to other codebases most easily. The author says to write the contract before touching the build config. The config can be reversed in an afternoon, while an unwritten contract becomes tribal knowledge that breaks when someone new ships a first remote ^[16].