HomeReadTools deskMigrating React Micro Frontends to Rspack: A Deep Dive into Module Federation Challenges
Tools·Jun 14, 2026

Migrating React Micro Frontends to Rspack: A Deep Dive into Module Federation Challenges

This review evaluates a complex migration path for 9 React micro-frontend applications from CRA/Webpack 5 to Rspack, considering both per-app and monorepo strategies with Nx. The Answer Up Front For…

This review evaluates a complex migration path for 9 React micro-frontend applications from CRA/Webpack 5 to Rspack, considering both per-app and monorepo strategies with Nx.

The Answer Up Front

For DaysAreGone_ForMe's specific setup, moving to Rspack per app is the lower-risk, incremental path, especially given the reliance on Webpack Module Federation's runtime specifics. This approach allows for phased migration and maintains existing repository boundaries. Nx+Rspack offers long-term benefits for shared code and build performance but introduces significant upfront migration complexity and a steeper learning curve for the monorepo paradigm. Prioritize Rspack's Module Federation compatibility and HMR stability before committing to a monorepo.

Methodology

This v0 review draws on the founder's detailed problem description and specific questions published on Reddit by user DaysAreGone_ForMe on May 22, 2026. The analysis is based on publicly available documentation for Rspack and Nx, and general industry knowledge regarding micro-frontend architectures and bundler migrations. Independent benchmarks of Rspack's Module Federation implementation, HMR behavior, or production stability for this specific setup are pending. Update cadence: re-tested when claims diverge from observed behavior or new public artifacts emerge.

Tool name + version + date observed: Rspack (latest stable, as of May 2026), Nx (latest stable, as of May 2026). Source signal URL: https://www.reddit.com/r/webdev/comments/1tkq7ym/migrating_9_micro_frontend_apps_from_cra_craco/. What's covered in this review: founder's current architecture, proposed migration options, and specific technical questions regarding Rspack's Module Federation, SASS/MUI compatibility, shared singleton dependencies, dynamic remote loading, and HMR. What's NOT covered: independent performance benchmarks, long-term workflow impact beyond the founder's initial assessment, or exhaustive edge-case testing.

What It Does

The Current Micro Frontend Architecture

DaysAreGone_ForMe manages nine distinct React 18 applications, each in its own Git repository with independent CI/CD pipelines. All apps are currently built using create-react-app (CRA, react-scripts 5.0.1), CRACO 7, and Webpack 5. The core integration mechanism is Webpack Module Federation.

The architecture employs a thin routing host that dynamically loads remote applications at runtime based on the URL. Unlike typical “shell owns everything” setups, each remote app functions as a full, standalone application, complete with its own routes, navigation, and Redux store. Authentication is centralized via an admin module, with other remotes checking localStorage for tokens and redirecting to the admin login if needed. Dynamic script injection (__webpack_init_sharing__, window[scope].init(), container.get(module)) is used for loading remote bundles. The tech stack includes TypeScript, Redux Saga, MUI 5, PrimeReact, and SASS.

Proposed Migration Paths

The founder is evaluating two primary options. Option A: Rspack (drop-in per app) involves replacing the CRA/CRACO/Webpack configuration with Rspack in each of the nine applications. This maintains the separate repository structure and allows for a phased, app-by-app migration, leveraging Rspack's claimed remoteEntry.js compatibility with Webpack-built hosts.

Option B: Nx + Rspack (monorepo) entails consolidating all nine applications into an Nx monorepo, using Rspack as the bundler within the Nx ecosystem. This option aims for improved long-term maintainability through shared Nx libraries for common components, but it represents a significantly larger upfront migration effort.

What's Interesting / What's Not

Rspack's Module Federation Compatibility

The most critical aspect of this migration is Rspack's Module Federation implementation. DaysAreGone_ForMe's reliance on dynamic script injection via __webpack_init_sharing__ is a Webpack-specific runtime detail. Rspack's claim of producing a compatible remoteEntry.js is essential, but the depth of this compatibility—especially with complex shared singleton configurations for react, react-dom, and other libraries—is where issues typically arise. While Rspack aims for Webpack compatibility, subtle differences in runtime behavior, particularly around shared module resolution and versioning, can lead to hard-to-debug production issues. The founder's concern about HMR across host-remote boundaries is also valid; consistent HMR behavior is a common challenge in federated setups, even within pure Webpack.

Monorepo vs. Distributed Apps

The choice between a per-app Rspack migration and an Nx monorepo is a strategic one. A per-app Rspack migration (Option A) is a tactical move to improve build performance without altering the architectural boundaries or team workflows significantly. It minimizes immediate disruption. The Nx monorepo (Option B), conversely, is a substantial architectural shift. While Nx's caching and workspace management can indeed offer significant build performance benefits and enforce consistency across many applications, the migration overhead for nine existing, independent applications is considerable. This includes refactoring shared components into Nx libraries, adapting CI/CD pipelines, and onboarding the team to monorepo tooling. The “painful” aspect of monorepo migration is not just technical but organizational.

Missing Alternatives and Considerations

DaysAreGone_ForMe correctly ruled out Vite Module Federation due to the Webpack-specific runtime. However, the core challenge is not just the bundler, but the migration strategy. A key consideration often overlooked in such migrations is the cost of maintaining a hybrid environment during the transition. If Rspack remotes can genuinely be consumed by a Webpack host, this mitigates risk. However, the reverse (Webpack remote by Rspack host) also needs validation for future flexibility. The founder's question about src/ code changes is important; ideally, it should be minimal, but bundler migrations often expose implicit dependencies or non-standard practices that require minor code adjustments.

Pricing

Rspack is an open-source project and has no direct cost. Nx offers open-source tooling, with commercial support and advanced features available through Nx Cloud, which is priced based on usage (e.g., build minutes, cache size). Pricing for Nx Cloud is available on their website (snapshot May 2026).

Verdict

For DaysAreGone_ForMe's immediate goal of improving build performance without a complete architectural overhaul, the Rspack (drop-in per app) migration is the most pragmatic first step. This approach allows for isolated testing of Rspack's Module Federation compatibility, particularly with the existing dynamic script injection pattern and shared dependencies, before committing to a larger monorepo transformation. If Rspack proves stable and compatible in this federated context, the performance gains alone will justify the effort. The Nx monorepo, while offering long-term benefits for a nine-app setup, represents a higher-risk, higher-reward endeavor that should only be pursued after validating Rspack's core functionality within the existing micro-frontend boundaries.

What We'd Test Next

A v2 review would involve setting up a minimal host-remote pair, one built with Webpack 5 and the other with Rspack, to rigorously test Module Federation compatibility, especially around shared singletons and dynamic script injection. We would benchmark HMR stability and latency across host-remote boundaries. We would also simulate a production environment to identify any gotchas with multiple remotes sharing dependencies. Finally, we would build out a small Nx workspace with two federated Rspack apps to assess the actual migration effort and caching benefits for a multi-app scenario.

The investor read

This migration signal highlights the ongoing pain points with Webpack's build performance and configuration complexity, particularly in mature micro-frontend architectures. The move towards Rust-native bundlers like Rspack (and Turbopack) is a clear trend driven by developer experience and CI/CD cost optimization. The founder's dilemma between a drop-in bundler replacement and a full monorepo adoption (Nx) reflects a broader market tension: incremental improvement versus strategic re-platforming. Tools that simplify complex migrations, offer robust compatibility layers, or provide clear pathways to performance gains without requiring a complete architectural rewrite will see continued adoption. Nx's value proposition for monorepos remains strong, but the friction of initial migration for existing distributed systems is a significant barrier. Investment opportunities exist in tools that abstract away bundler complexity or provide seamless, incremental migration paths for large-scale legacy frontends.

Sources · how we verified
  1. Migrating 9 Micro Frontend apps from CRA + CRACO + Webpack 5 to Rspack (or Nx + Rspack) — anyone done this? What issues did you face?

Every claim ties to a primary source. See our methodology.

Reported by the Riley desk on Founderr Pulse’s Tools beat. Every factual claim is tied to a primary source and linked; anything that can’t be stood up doesn’t run. Founderr (RIKHATH LLC) is the accountable publisher and corrects in place. How we work · About · File a correction.
R
Riley

The Riley desk covers tools — what founders are building with, switching to, and abandoning. Every claim is sourced and linked. Operated by Founderr (RIKHATH LLC) See the desk →

Founderr Pulse — free & independent. The desk for people who build & back.