标签：#webpack

This series walks through an actual enterprise microfrontend platform, end to end: one Host shell, three shared platform microfrontends, a manifest-driven mechanism for mounting any number of independently-owned domain microfrontends, a full OIDC auth flow, and a CI/CD pipeline. Every code snippet in this series is real and traceable to the actual boilerplate it's built from, on GitHub . Part 1 is the decision everything else in this series depends on: why Module Federation , and not one of the two other credible options. The one requirement that rules everything else out Strip away the buzzwords, and an "enterprise microfrontend platform" only has to guarantee one thing: a team ships a change to their part of the app without anyone else redeploying anything. Not "in theory, with enough coordination" — actually, mechanically, true. If shipping one team's bug fix requires a platform team to cut a release, this isn't microfrontends — it's a monolith with extra steps. That single requirement rules out more than it looks like it should. It rules out compiling every team's code into one shared build (that's just a single-page app with more steps). And it rules out anything where the Host app needs to know, at its own build time, which teams' pages exist and which version of each — because "known when the Host was built" and "deployed independently of the Host" are opposites. The decision Use Webpack 5 Module Federation , in runtime-composition mode, as the platform's way of putting every team's page together into one app: The Host ships with an empty list of remote apps built in. Instead, it looks up every team's page from a small list — a manifest — that it fetches fresh every time the app loads. React, the shared state layer, and the shared design system are all declared as singletons : every team's page gets the exact same running instance of each, not its own separate copy. "Deploying" a team's page means adding or updating one entry in that manifest. The Host itself

Contributor: Nikhil Kumar Rajak ( @ryzrr ) Organization: webpack · Project: webpack-doc-kit Mentors: Aviv Keller ( @avivkeller ), Claudio Wunder ( @ovflowd ), Sebastian Beltran ( @bjohansebas ) Teammates: Mohamed Shams El-Deen ( @moshams272 ), Tushar Thakur ( @TusharThakur04 ) Period: 25 May to 17 August 2026 The problem webpack's docs lived at webpack.js.org and every API change meant somebody updating them by hand. Pages go stale and nobody notices until a reader does. webpack-doc-kit fixes that. It takes webpack's TypeScript declarations, runs them through TypeDoc, hands the output to nodejs/doc-kit for linking and UI, and produces a site that regenerates itself. We split the work three ways. Shams took AST parsing and content, Tushar took routing and navigation and UI, and I took the operational side: how docs get generated on a release, versioned & deployed. My six deliverables were PR-based doc sync, release-aware doc generation, versioned output folders, a deployment pipeline, CI validation before merge, and README fetch automation. All six shipped. Merged PRs in webpack-doc-kit 31 Lines added / removed +1,959 / −1,419 Distinct files touched 89 First / last merge 28 May ( #110 ) / 14 Aug ( #241 ) Merged PRs in other repos 2 Upstream issue filed and fixed 1 Everything below is merged into main . Nothing is open or pending. The release pipeline webpack releases happen in webpack/webpack . The docs live in webpack/webpack-doc-kit . A release in one needs to produce updated docs in the other with nobody doing anything. #110 set up versions.json as the single source of truth everything downstream reads, plus the script that maintains it and the workflow that runs it. My mentor proposed an object schema with latest , label , major , exactVersion , commit and frozen per entry. Review cut it to a flat array of tag strings, because everything else is derivable from the semver string and position [0] with unshift() already tells you which is latest. Right call, and I d