Webpack5 Playground

My little playground for experimenting with Webpack 5 Module Federation
Alternatives To Webpack5 Playground
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Emp2,07214a month ago9September 27, 20215otherTypeScript
EMP Micro FE Base on webpack 5 & module federation
a day ago8apache-2.0JavaScript
A self-hosted lightweight federated messenger for the decentralized web.
Apollo Feature Requests122
7 months ago248other
🧑‍🚀 Apollo Core Platform Feature Requests | (no 🐛 please).
Web Apps65
8 months ago12TypeScript
RingCentral Web Apps Framework
Storybook Webpack Federation Plugin4812 years ago5June 30, 20208mitJavaScript
Exposes all the components in your Storybook as Webpack 5 federated components.
Microfrontends Boilerplate Module Federation40
3 months ago10JavaScript
Complete module federation boilerplate | Cypress, jest, testing library, MUI 5, styled-components, Husky, Zustand and others.
Aws Credentials Broker39
2 months ago2August 17, 20208mitGo
AWS Credentials Broker - Grants temporary AWS credentials for Google federated users
React Native Amplify Cognito Example18
5 years ago1mitJavaScript
React Native Example: Login by AWS Amplify with AWS Cognito Identity Pools (Federated Identities)
Service Manual14
a year ago11mitJavaScript
Digital Guides
a year agoapache-2.0TypeScript
Take back control of your data with IndiView, an app for self-hosted digital identities on CoreDB nodes. Designed for Android and iOS, supports messaging and personalized content feeds.
Alternatives To Webpack5 Playground
Select To Compare

Alternative Project Comparisons

Webpack 5 Playground

This is a playground to experiment with Webpack 5, in particular its new ModuleFederationPlugin

Getting Started

yarn && yarn dev

This will start 3 webpack dev servers and 1 storybook server:

Webpack Dev Servers:

  • The Header Server (http://localhost:3001)
  • The Footer Server (http://localhost:3002)
  • The App Server (http://localhost:3000)

Storybook Server:

  • The "Design System" (Chakra-UI 'cause I ain't writing no fancy components. This is just to explore Storybook as a Webpack 5 remote entrypoint) (http://localhost:6006)

The Main App pulls dependencies from the Header, Footer, and Design System servers, at runtime, and "stitches" them together to form a full application. It's magic 🌟

Prove that it works

Navigate to http://localhost:3000 to see the awesome app ;)!

Now let's say the Design System team wants to make a change. They want to remove that ugly border on the Box component in the design system. Let's go ahead and do that:


const StyledBox = styled(Box)`
  border: 2px solid black; <-- Remove this line

Go ahead and save and let Storybook rebuild your component. Now refresh the page on http://localhost:3000. Notice that the border on our header and footer is gone! Again, our app does not have a dependency on our Design System at build time (check its package.json if you don't believe me), but at run time. The components are fetched by Webpack at runtime using Module Federation and made available to our app. Your Storybook is now a component host for your design system, the one source of truth for documentation and distribution.

So what?

This means any updates to your design system happen the instant your design system changes, across all of your apps. No more bumping dependencies and creating new artifacts to get those design system changes live.


Typically, frontends are monolithic, having a manifest of dependencies, usually a package.json, and is deployed altogether as a single artifact. Any components that the application depends on is ususally included as a versioned dependency in the package.json and then imported throughout the project. This works great for small applications.

As an application grows, different teams may have responsibility over different parts of the app or components the app depends on. Addtionally when new versions of the components are published, versions have to be bumped in the main application package.json, new artifact be built, and deployed, in order for those components to truly be "live". We now have multiple teams coupled to single release cycle -- Welcome to the Monolith!

This repo is cutting against that approach, and is effectively an experiment in a microfrontend architecture. There is a lot of baggage with the term "microfrontend", but here is a nice writeup about this approach here

What's in the repo

In this repo, we have the Header, Footer, Design System, and App "teams". These teams are responsible for parts of an application, developing, testing, and deploying those pieces. The most valuable thing this approach gains us is that development teams can ship new versions of their parts of the application, live to production, without having to depend on the release cycle of the main application. The pieces are "stitched" at runtime in the main application using Webpack 5 Module Federation. This feature is still in beta


Popular Federation Projects
Popular Reactjs Projects
Popular Networking Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.
Design System