└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # How do I secure the remote modules? 2 | 3 | Remote modules are simply JavaScript files. They have no more security exposure than split bundles, which 4 | is a feature that has been available for years. 5 | 6 | # I don't see state changes reflected between two different host applications 7 | 8 | Module Federation shares code, not state. If you want components hosted on different pages to share state you need to use normal 9 | state sharing mechanisms like REST or GraphQL API, or Websockets, or a servie like Firebase or Supabase. 10 | 11 | # How does Module Federation handle routing? 12 | 13 | Module Federation doesn't manage routes. Module Federation is just a mechanism to share code between applications. 14 | What type of code you choose to share; components, routes, utility functions, i18n strings, is completely up to you. 15 | But how you use that code in terms of routes, is completely up to you. 16 | 17 | # Does Redux/Context/MobX/Valtio/Zustand/etc. work with Module Federation? 18 | 19 | Yes, but, you will probably need to expose the store singleton from one application and consume it in your remote modules 20 | in order to ensure that you are using the same global data store (or context). 21 | 22 | # Doesn't a Monorepo do what Module Federation does? 23 | 24 | No, a monorepo makes it easy to share code between applications at *build time*, where Module Federation makes it possible to 25 | share code at runtime. If you have a component that is used in three different applications in a monorepo and you want to ensure that 26 | a change to that component is deployed to all the applications you will need to redeploy all three applications from the monorepo. 27 | With Module Federation and runtime dependencies you deploy the component once and it is consumed by all three applications at runtime 28 | so the updating is instantaneous. 29 | 30 | # Is Module Federation the only way to do Micro-Frontends? 31 | 32 | No. A Micro-Frotend is just a self-contained component that manages its own state and connection to its Micro-services. You can 33 | implement Micro-Frotends using npm modules hosted in different repositories, or in a single repository as a mono-repo, or using Module 34 | Federation. Which mechanism you choose depends on your requirements. 35 | 36 | # Can I use a mono-repo in conjunction with Module Federation? 37 | 38 | Absolutely. You can share the same component both dynamically using Module Federation and as build-time dependency as a fallback using a 39 | mono-repo. 40 | 41 | # How does Module Federation relate to SingleSPA? 42 | 43 | SingleSPA is a system that makes it easy to host components written in different frontend frameworks on the same page. For example a React application 44 | can host an Angular component packaged as a SingleSPA parcel. SingleSPA can use Module Federation to load the component parcels. So these two 45 | technologies can be used together. Module Federation does **not** have any mechanism that allows you to run code from one view framework within a 46 | different view framework. Though it will happily allow you to import that code. 47 | 48 | # How do I share CSS using Module Federation? 49 | 50 | You can only share JavaScript code with Module Federation. You can't share CSS as CSS, or images as images. One approach to styling Micro-Frontends 51 | is to use a shared stylesheet between the host applications, and to use a CSS-in-JS solution, like emotion, to refine the styles of the 52 | components. 53 | 54 | # How does TypeScript work with Module Federation? 55 | 56 | Module Federation shares JavaScript files at runtime. When the TypeScript files are compiled and deployed the types are gone. 57 | One recommendation for using type with Module Federation is to use shared "contract" libraries that define the types of exposed modules. 58 | And these contract libraries should be used by both host and remote to ensure that shared code conforms to those contracts. 59 | 60 | # Why Doesn't Tailwind Work? 61 | 62 | Tailwind has a pre-processor that looks through all the code involved in the build and figures out what to include in the CSS. 63 | Because your run-time modules are not parsed by the pre-processor it doesn't see those classes and thus the classes don't 64 | exist in the application's CSS. You can add classes to the `safelist` and that would include them in the application build 65 | even if the pre-processor didn't find them at build time. But this means any time you add classes to your run-time loaded MFEs 66 | you would have to adjust the `safelist` in all consuming applications if those applications didn't already use that class. 67 | 68 | Tailwind after release 3 is not a good choice for doing MFEs because of this build-time pruning. Any CSS-in-JS technology 69 | is currently the best option for module federation. 70 | --------------------------------------------------------------------------------