@module-federation/enhanced

@module-federation/enhanced is the primary package of the Module Federation project — a superset of webpack 5’s built-in Module Federation that adds a bundler-agnostic runtime, a shared-dependency manifest, dynamic TypeScript type hints across federated remotes, and a pluggable runtime-plugin system. It ships the wrapper plugins developers actually import (ModuleFederationPlugin, ContainerPlugin, ContainerReferencePlugin, SharePlugin, ConsumeSharedPlugin, ProvideSharedPlugin, FederationRuntimePlugin, AsyncBoundaryPlugin, HoistContainerReferencesPlugin) and works identically on top of either webpack or Rspack.

Teams building micro-frontend architectures use it to split a large frontend into independently owned, independently deployed applications that still share common dependencies (React, design-system packages, utility libraries) at runtime instead of bundling duplicate copies. It also ships an mf CLI (npx mf dts) for generating and fetching cross-application TypeScript types for federated remotes, so consuming a remote module still gets full type safety.

What You Get

• ModuleFederationPlugin - the main webpack/Rspack plugin for exposing and consuming federated modules, wrapping the underlying core plugin so it works the same way on either bundler.
• Federation Runtime & runtime plugins - a runtime layer (runtime.ts) with a runtimePlugins option for injecting custom behavior into how remotes are loaded and shared modules are resolved.
• Shared-dependency plugins - SharePlugin, ProvideSharedPlugin, and ConsumeSharedPlugin implement singleton mode, version-range matching (requiredVersion), and eager loading for dependencies shared between host and remotes.
• Container plugins - ContainerPlugin, ContainerReferencePlugin, and HoistContainerReferencesPlugin implement the low-level exposing/consuming container machinery (entry modules, dependencies, factories) that federation is built on.
• mf CLI - a bundled command (npx mf dts) for generating and fetching TypeScript type definitions for remote modules, so consumers of a federated remote keep full type checking.
• Dual webpack/Rspack support - the same plugin options work against either bundler via a BaseWrapperPlugin abstraction that resolves the correct bundler path at apply-time.

Common Use Cases

• Splitting a large single-page application into independently deployable micro-frontends owned by separate teams.
• Sharing a design-system or common-dependency bundle (React, a component library) between a host app and multiple remotes without duplicating it in every bundle.
• Migrating an app from webpack to Rspack (or running both) without changing Module Federation configuration.
• Building a plugin-in-app architecture where features are loaded as separately versioned, separately deployed remote modules at runtime.
• Getting full TypeScript autocomplete and type checking when importing a module exposed by a different, independently built application.

Under The Hood

Architecture The codebase is split into a thin wrapper/ layer (ModuleFederationPlugin, ContainerPlugin, SharePlugin, etc., all extending BaseWrapperPlugin) and a lib/ layer holding the actual webpack-compiler-facing implementation (lib/container/* for exposing/consuming containers — ContainerEntryModule, ContainerEntryDependency, ContainerEntryModuleFactory — and lib/sharing/* for shared-dependency resolution — ProvideSharedPlugin, ConsumeSharedPlugin, ShareRuntimeModule). BaseWrapperPlugin is the load-bearing abstraction: it sets a FEDERATION_WEBPACK_PATH environment variable so the correct bundler instance is used, then lazily require()s the matching core plugin implementation at apply() time rather than at import time, which is what lets the same public API run unmodified against either webpack or Rspack. Every public entry point (index.ts, webpack.ts, rspack.ts, runtime.ts) is a thin re-export surface onto this wrapper/core split, and changing BaseWrapperPlugin’s contract would ripple through every plugin in the package.

Tech Stack Written in TypeScript and built with tsdown (a Rolldown-based bundler) into dual CommonJS/ESM output plus hand-copied .d.ts declarations. It depends on sibling workspace packages resolved via workspace:* — @module-federation/sdk, runtime-tools, dts-plugin, managers, manifest, rspack, cli, error-codes — plus schema-utils for options validation and tapable (webpack’s own hook system) for plugin composition. webpack, typescript, and vue-tsc are all optional peer dependencies, reflecting that it must work whether or not any of them are present. The monorepo is orchestrated with pnpm workspaces, Turborepo, and Nx-style caching, with Renovate managing dependency updates.

Code Quality The package has an extensive, integration-heavy test suite: unit tests under test/unit/ and test/compiler-unit/ for the sharing and container plugins, plus full webpack/Rspack compilation fixture tests under test/configCases/ (tree-shaking-share, sharing, layers, container, build-version) that exercise real compiler output rather than mocking it. CI runs a dedicated build-and-test workflow alongside a dozen framework-specific end-to-end workflows (Next.js dev/prod, Modern.js SSR, Metro, router, runtime, tree-shaking). Type safety is intentionally loosened for velocity, though: the monorepo’s shared tsconfig.base.json sets strict: false, and the root ESLint config disables no-explicit-any, no-unused-vars, and prefer-const, which shows up directly in the code (BaseWrapperPlugin types its core options as any). Error handling favors pragmatic try/catch-with-fallback over typed error handling.

What Makes It Unique Rather than just re-exposing webpack 5’s built-in Module Federation, this package layers on a bundler-agnostic wrapper so the same configuration runs against Rspack as well as webpack, a Federation Runtime with an injectable runtime-plugin system, a shared-dependency manifest, and a generated cross-application TypeScript type-hinting pipeline (via the bundled mf dts CLI) so that importing a module built and deployed by a completely different application still type-checks. That combination of cross-bundler portability and build-time-generated cross-app types for a micro-frontend architecture goes meaningfully beyond feature parity with vanilla webpack Module Federation.