When configuring ModuleFederationPlugin in Webpack for a remote and a host, what do the 'exposes' and 'remotes' options each declare, and how does the 'filename' option relate to the generated container file?

## The two sides of one config The `ModuleFederationPlugin` is configured differently depending on which role a Webpack 5 build plays, and two options — `exposes` and `remotes` — are the primary vocabulary for declaring that role, with `filename` controlling how the resulting container is named and found. | Option | Set on the app acting as | What it declares | |---|---|---| | `exposes` | a remote | a public name to a local file path | | `remotes` | a host | a local alias to a resolution string | | `filename` | a remote | the container bundle Webpack emits | ## exposes — the remote's public contract `exposes` is used on the side acting as a remote — the app offering modules for others to consume. It is a map from a public 'friend name' to a local file path, for example { './ProductList': './src/components/ProductList' }. - For every entry, Webpack builds a separate async chunk containing that module and its exclusive dependencies, and registers it under the given public name inside the container it builds for this app. - The public names are deliberately decoupled from the real file paths and directory structure — a consumer of this remote never needs to know that ProductList actually lives at `src/components/ProductList.tsx`; it will import it as `catalog/ProductList`, where catalog is this app's federation name, a value set alongside `exposes` in the same plugin config. This indirection is what lets the remote refactor its internal file layout freely without breaking any host that consumes it — the exposed name is the stable public contract, comparable to a package's public API surface versus its internal module structure. ## remotes — the host's address book `remotes` is used on the side acting as a host — the app that wants to consume another app's exposed modules. It is a map from a local alias to a resolution string that tells Webpack's runtime where to find that remote's container at runtime, for example { catalog: 'catalog@https://cdn.example.com/catalog/remoteEntry.js' }, or in the newer object form { catalog: { external: 'catalog@https://cdn.example.com/catalog/remoteEntry.js' } }. The `@` in that string separates the federation name the remote registers itself under (used to look it up in the browser's global federation registry once loaded) from the actual URL of its container script. Given this entry, any code in the host can write `import('catalog/ProductList')`, and Webpack's runtime resolves catalog to the registered URL, fetches it if not already loaded, and resolves ProductList against that remote's `exposes` map. ## filename — naming the container `filename` controls the name Webpack gives to the container bundle it emits for a remote — most commonly set to `remoteEntry.js`, which is why that name shows up everywhere in Module Federation documentation, but it is just a convention, not a hard requirement; a build could name it `container.js` or version it as `remoteEntry.2024-06-01.js`, as long as every host's `remotes` URL for that app points at the exact same filename that was actually emitted. This matters operationally: the container filename and its hosting URL together form the contract a host is coupled to, so teams commonly either - version the filename itself, forcing a coordinated update on the host side for breaking changes, or, - more commonly, keep the filename stable and instead let the container's internal get/init protocol and shared-dependency version negotiation absorb compatibility, deploying new remote code under the same stable URL so hosts pick it up automatically on next load. ## Why the model is two-sided The reason this two-sided configuration model exists is to keep the coupling between apps as thin and declarative as possible: a remote's `exposes` config is a complete description of its public contract, and a host's `remotes` config is a complete description of what external contracts it depends on and where to find them — neither side needs visibility into the other's build, source layout, or internal module graph. This mirrors, at the level of separately deployed applications, what a package.json dependency and its package's exported entry points do for code shipped through npm, except the resolution happens over HTTP at runtime in the browser instead of at install time on disk. ## The main failure mode The main failure mode teams hit here is **naming drift and typos**. Three independently typed strings must line up exactly, with no build-time type checking across the boundary by default: 1. the `exposes` names, 2. the federation name, 3. the `remotes` alias. Because of that, a remote renaming an exposed module or its federation name silently breaks every host still using the old string, usually surfacing as a runtime 'Module not found' or similar error rather than a build failure. Larger organizations mitigate this by generating and publishing TypeScript declaration files for each remote's `exposes` map so hosts get IDE-level and CI-level type checking against a remote's real exposed API, closer to what a monorepo would give for free.