EMP v4: a micro-frontend build layer on Rspack 2 and Module Federation 2

What EMP v4 is for, and who ends up using it

EMP v4 targets a specific situation: one web product is split across several teams, each shipping its own frontend module, and someone has to make those modules load inside each other at runtime. The README describes it as a micro-frontend engineering tool for the modern web that uses one configuration to handle host, remote, shared, manifest, DTS and runtime adaptation, so teams can focus on module splitting and delivery. That sentence is the whole pitch, and it is a reasonable one, because the work it removes is mostly configuration glue rather than application code.

The people who end up using it are frontend platform engineers and build engineers, not product feature developers. A product developer consumes a remote module through the host shell. The platform engineer is the one who decides which dependencies are shared, which are singletons, how version negotiation resolves when two remotes disagree, and what type declarations the host sees. EMP v4 puts all of that in the same config surface. The repository layout supports this reading: packages/ holds the CLI and plugins, apps/ holds example applications, and the root package.json defines workspace scripts such as emp, emp:build and mf that drive those packages.

If your project is a single application with one deploy pipeline, this tool is overhead. Nothing in the README suggests EMP v4 helps a monolithic frontend, and the concepts it exposes (host, remote, shared) only earn their keep once modules are delivered separately.

The mechanism: Rspack 2 compiles, Module Federation 2 connects

EMP v4 is a configuration and plugin layer, not a new bundler. The release notes for v4.0.1 name Rspack 2.2 and Module Federation 2.9, and the README states the project is based on Rspack 2 and supports Module Federation 2. So the pipeline is: Rspack compiles each application or library, Module Federation wires the compiled remotes to the host at runtime, and EMP supplies the config translation, the shared dependency policy and the type generation around them.

The README lists four capabilities that map onto that pipeline. Federation build covers host, remote, shared dependencies and type declaration generation. The build base covers development, build, preview and analysis. Output format is explicit: build.format selects between an ordinary script and native ESM, and build.targets sets a single compatibility range. The fourth is a TypeScript 7 stable type baseline, which the README says guards compatibility across CLI, plugin, DTS and style types.

Two of those deserve attention. First, build.format is a real decision point: choosing native ESM changes what your host can consume and how remotes are loaded, and the README presents it as a choice rather than a default you can ignore. Second, the DTS generation is the part teams usually hand-roll, and having it inside the same config is the strongest practical argument for the tool. The repository also carries a packages/ tree with plugin packages, and the root build script enumerates @empjs/plugin-react, @empjs/plugin-vue2, @empjs/plugin-vue3, @empjs/plugin-lightningcss and @empjs/plugin-postcss, which matches the README's claim of out-of-the-box React, Vue 2/3, Tailwind CSS and Lightning CSS support.

Installing EMP v4 and running a first federated build

The README says the v4 stable release installs from npm latest, and that quick start and migration steps live in docs/v4-migration.md. It does not print an install command, and neither does the root package.json, which is a private workspace manifest whose scripts drive the monorepo rather than a consumer install. So there is no command line to copy here; the README names npm latest as the distribution channel and docs/v4-migration.md as the place the steps are written down.

What the README does name is the configuration surface you work with once the CLI is in place. It states that build.format selects between an ordinary script or native ESM, and that build.targets sets a unified compatibility range. Those two keys are the ones the README puts forward as the output-format decision, and the README gives no example block for them, so the shape below is the key names it lists rather than a snippet copied from the repository. Check docs/v4-migration.md for the accepted values before using it.

The other piece the README calls out by name is the sharing plugin from v3, which is still supported. The README writes it as pluginRspackEmpShare(...) and says keeping it reduces rework in existing projects, so if you already run EMP v3, start there rather than rewriting your federation config. What you should see after a build is a compiled output in the format you selected, plus generated type declarations for the federated modules, since the README lists DTS generation as a built-in capability. It does not show expected console output, so treat the presence of the declaration files and the chosen output format as your check.

Where EMP v4 will not help you

The clearest limitation is the dependency floor. EMP v4 sits on Rspack 2 and Module Federation 2. If your organisation standardised on webpack 5 with Module Federation 1, or on a different bundler entirely, adopting EMP v4 means moving two layers at once, and the README's migration path assumes you are moving from EMP v3 rather than from another toolchain. The migration guide is the only document the README points to, and it is a migration guide for EMP itself.

A second gap is operational. The README documents configuration and capabilities, but it does not document rollback, version pinning strategy or what happens when a remote at runtime serves an incompatible shared dependency version. The README does say EMP v4 handles version negotiation and singleton dependencies centrally, which reduces repeated configuration, but it does not describe the failure behaviour when negotiation cannot be satisfied. If you need a documented answer to that before shipping, the README is silent and you will have to read the source or ask in the community channel.

The third case is simpler: if your frontend is one deployable unit, or if the modules you split never need to load each other at runtime, Module Federation is the wrong mechanism and EMP v4 is the wrong layer. Build-time code sharing through a package registry solves that without a runtime loader.

EMP v4 against hand-written Module Federation config

The honest alternative is not a different micro-frontend framework; it is writing the Module Federation configuration yourself on top of Rspack or webpack, using @module-federation/sdk directly. The README badge for the Module Federation version reads the @module-federation/sdk dependency from @empjs/share@latest, which tells you what EMP is wrapping.

The difference in approach is where the policy lives. With hand-written config, each application owns its own shared dependency block, its own singleton declarations, its own remote entry configuration and its own type generation step. That is more code, but every decision is visible in the application repository, and there is no intermediate layer to debug when a remote fails to load. With EMP v4, those decisions move into a shared config shape and a plugin, and the README's stated benefit is that version negotiation, singleton dependencies and runtime loading are handled in one place, reducing repeated configuration. You trade per-application explicitness for consistency across applications.

Which is better depends on count. Two applications with one shared library do not need a layer. Eight remotes maintained by four teams, each with slightly different shared dependency rules, is exactly the situation where a shared policy layer pays for itself. EMP v4 also brings the plugin packages for React, Vue 2/3, Tailwind CSS and Lightning CSS, which hand-written config leaves to you.

Maintenance, upgrades and what the MIT licence covers

The repository is not archived, and the last push was on 2026-09-21. The most recent release is v4.0.1, published on 2026-09-01, described in the release notes as EMP v4.0.1 with Rspack 2.2 and Module Federation 2.9. Before that, v4.0.0 landed on 2026-07-16, with v4.0.0-rc.5 the same day. That is a recent, short release history at the v4 line, and the project is a pnpm workspace with a CHANGELOG.md at the root, so upgrade notes have a place to live.

The upgrade cost is mostly inherited. Because EMP v4 depends on Rspack and Module Federation, major bumps in either will reach you through EMP releases, and the plugin packages in packages/ (React, Vue 2, Vue 3, Lightning CSS, PostCSS) each track their framework's own release cadence. The root package.json shows the workspace pins a package manager through the packageManager field, and the CI-style scripts use corepack, so the toolchain version is part of the repository contract rather than something you pick freely.

The licence is MIT, taken from the repository and from the @empjs/cli manifest the README badge reads. MIT permits commercial use and modification with the copyright notice retained, but this is a description of the licence text, not legal advice. If you redistribute a modified CLI or plugin, check how you comply with the notice requirement in your own packaging.

Editorial conclusion

Adopt EMP v4 if your team already runs a Module Federation setup and wants host, remote, shared dependency and DTS configuration handled in one place, with React, Vue 2/3, Tailwind CSS and Lightning CSS plugins available. Do not adopt it if you want a plain single-bundle build, if you cannot move to Rspack 2 and Module Federation 2, or if you need documented rollback and upgrade procedures, because the README points only to the v4 migration guide and does not describe rollback. Verify first that @empjs/cli resolves to 4.0.1 (the release notes pair it with Rspack 2.2 and Module Federation 2.9), that your Node version satisfies the engine field on @empjs/cli, and that your existing pluginRspackEmpShare(...) configuration still loads under the v4 defaults.

Frequently asked questions

Official sources

1. empjs/emp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases