Death to the NgModule.
Micro-frontends used to be a nightmare of shared modules, scope collisions, and "entry components."
With Standalone Components, a micro-frontend is just a URL that exports a single Component class. No modules. No boilerplate.
Deep Dive: Version Skew Hell
Using MFEs doesn't magically solve dependency issues. If Host uses Angular 18 and Remote uses Angular 16, they might both try to load different versions of zone.js or rxjs.
Rule of Thumb: Force all MFEs to use the exact same version of Core Framework dependencies via a Monorepo policy.
02. Simplified Config
Using modern builders (like native federation or Nx), exposing a standalone component is trivial.
name: 'payment',
exposes: {'{'}
'./Component': './src/app/payment/payment.component.ts'
{'}'}
{'}'}
03. Communication Strategy
Don't: Shared Service
Sharing a singleton state service between MFEs couples them during build time and can lead to version mismatches.
Do: Custom Events / Signals
Use DOM Custom Events or a lightweight PubSub (window Signal) to dispatch actions like "PAYMENT_SUCCESS" that the Host listens to.
04. The Senior Engineer's Take
You probably don't need MFEs.
Micro-frontends introduce massive operational complexity (deployment coordination, versioning).
Only use this pattern if: You have multiple autonomous teams (20+ devs) effectively deploying to the same page separately. If you are one team, use a Modulith (Monorepo).