Next.js Support is in maintenance mode

[ScriptedAlchemy]

Deprecation Notice for nextjs-mf

We intend to deprecate (EOL) nextjs-mf, maintained by the core authors of Module Federation.

• Pages Router will remain "supported," and small, easy fixes will still be back-ported.
• No new or active development will take place from the core team.
• Community pull requests will continue to be merged.
• Vercel should be considered the primary point of contact for anything regarding module federation & next.js. I will provide some support and examples for migrating away from next.

---

If you are exploring microfrontends, do not use Next.js! It is a hostile framework and Vercel is an adversary of federation

---

Regarding "RSC Federation" Tweeted by Vercel

• Appears to be an update to Next.js Zones.
• Page refresh may still exist.
• Supports only vertical slicing.
• Incompatible with the current ecosystem.
• Client components may not be importable as they are in Module Federation.
• No code or state sharing.
• Uses optimistic prefetching to minimize page reload time between zones.

Sharing components like a Header across multiple apps does not seem possible—you would need to use npm or a monorepo.

If any of this information is inaccurate or new information emerges, I will amend this section.

User Options

Your best options are to contact Vercel or abandon Next.js.

• Since the Pages Router still works, Next.js 15 is probably safe.
• Next.js 16 is TBD; if it only requires a minor fix (as with Next.js 15), I will provide a patch.
• You can use the module-federation/runtime package directly without a compiler plugin, but code sharing will be limited since shared performs build-time chunking. This means remotes must use the same versions of dependencies as hosts, and Next.js builds cannot generate remote entry files—essentially, it can only act as a host system.

We highly recommend moving to a framework that works well with microfrontends:

• Modern.js works best and will introduce RSC + Federation support in 2025, providing a solid alternative. It powers all of ByteDance and is maintained by their infrastructure team, ensuring excellent support.
• Remix is also a good option.
• TanStack looks promising as well.

If anyone wishes to become the primary maintainer of nextjs-mf, you are more than welcome.

Timeline Until Total Deprecation

Barring any unforeseen circumstances, expect nextjs-mf to remain as functional as it is today until mid to end of 2026. This gives you approximately two years to make a plan.

Note: If Next.js 16 breaks Pages Router support beyond an easy fix, version 16 will not be supported.

What This Means:

• Updates to our runtime packages will still ensure existing unit tests for nextjs-mf pass.
• Around the end of 2026, nextjs-mf unit tests will be removed from continuous integration.
• We will no longer track its functionality.
• If Vercel introduces significant changes that break it before the 2026 EOL, it will be retired ahead of time—assuming it's not a simple adjustment to fix.
• Most git issues on this repo related to next.js will be closed, file issues with Vercel.

Reasoning

Many framework authors actively collaborate and want to support Module Federation. Next.js is not one of them to date. While there seem to be internal discussions at Vercel, we have seen no indication or received any contact regarding this. Given the track record, doubt anything will materialize

nextjs-mf has involved years of "fighting the framework," and without support from the framework authors, it has been a very slow decline. Considering the substantial time and effort required to keep it somewhat functional, it is simply not worthwhile.

Supporting Next.js has come at the cost of improving the greater ecosystem. Since we stopped focusing on the project at the start of 2024, the Module Federation ecosystem has drastically expanded. This is largely due to reallocating the bandwidth that previously went into nextjs-mf.

As an example, creating Module Federation v2 took about 3 months, supporting modernjs took a few weeks. Next regularly requires months of work

nextjs-mf was initially started in 2021. Early on, there was alignment between Vercel and the Federation group. We enthusiastically submitted a pull request to Next.js to upgrade it to Webpack 5 and advance mutual goals of implementing Module Federation in Next.js. Ultimately, it did not pan out as Turborepo was acquired and a different approach was taken, Next in general has optimized toward bigger and faster monoliths.

I have largely been obligated to maintain this project single-handedly due to the user base being large tech companies—you cannot simply abandon a project when challenges arise. Best efforts have been made over the years to keep the project going. While I have not personally used nextjs-mf in about two years, it has seen two major releases.

I believe I have gone above and beyond for the users of nextjs-mf. While it is indeed disappointing to retire the project, it is time.

its been real, its been good. But it hasn't been real good 👋

Update:
Contact with vercel was made, it appears that they have been experimenting with federation v2.
While nothing is actionable at this time - it is a encouraging to see consideration of first-class support.
If support does materialize, we will be happy to adjust this ecosystem to support Vercel's requirements.

[anthonyshew]

Hey, Zack. We did smooth some rough edges and improve documentation for Multi-Zones with Next.js, and, separately, we're still thinking about and experimenting with solutions for RSC Federation and module federation.

Thank you for all the work you've done for the Next.js community over the years and looking forward to your next projects!

[ScriptedAlchemy]

Hey, Zack. We did smooth some rough edges and improve documentation for Multi-Zones with Next.js, and, separately, we're still thinking about and experimenting with solutions for RSC Federation and module federation.

Thank you for all the work you've done for the Next.js community over the years and looking forward to your next projects!

Glad to hear it! If vercel ever does decide to support module federation - we will be happy to resume support or adjust the ecosystem if there's any concern. Maybe by 2027 vercel will make some moves and users won't be left out in the cold.

It's just too much to support a framework who, as it stands today, doesn't want it.

Appreciate the first class consideration of microfrontends on next.

All the best, you know where to find me. 😉

[tamusjroyce]

Hi Zach, what alternative frameworks do you suggest?

[ScriptedAlchemy]

Hi Zach, what alternative frameworks do you suggest?

ModernJS will be the best for federation since it's a first-class feature and supports ssr etc.

Otherwise, anything that isn't owned and operated by vercel should be substantially better. Next has worst support, least features, most problems.

TanStack
ModernJS
Remix
Nuxt
Rsbuild
The Boring Stack
Vite based apps, but no ssr or typescript support.

[prakashmallow]

@ScriptedAlchemy Does module federation support React.js in the future? I'm asking because React 19 will include an RSC in the next major release.

[ScriptedAlchemy]

Yes, it will. ModernJS will likely ship first with RSC support. Our teams are waiting for v19 stable to arrive, but RSC is already in the quarterly plans. Rspack has already begun work on the Rust side, etc. However, the APIs for RSC have changed a few times, so there’s no point in doing it until we actually have the final API; otherwise, it’s pulling bandwidth away from other work. Once it lands, we will start looking into it. It likely won’t take much work to support, given the historical performance of the infrastructure team.

[lukovskij]

Hi @ScriptedAlchemy ! I am working with Module Federation 2.0 and the @module-federation/enhanced/runtime package. Could you please clarify if it’s okay to use Next.js (App Router) as a host and import remoteEntry.js at runtime from a React SPA in an NX monorepo?

[ScriptedAlchemy]

App router is entirely unsupported. My plugin will automatically fail your next build if I detect an app router.
Technically, the federation did always partially work with the app router but caused too many GitHub issues to be opened. Users kept trying to use it even though the documentation stated it doesn't work. So I actively block federation from working if you use the app router at all.

You can try with the vanilla runtime package... but future users are on their own if they attempt to use federation with Next.js.

Beyond migrating away from Next.js - which i will provide offramp support for, users should consider Vercel the primary point of contact for module federation from now on.

If i could block new installs of nextjs-mf, I would.

A safe assumption is this: nothing in my ecosystem will work with anything Vercel owns. If you find a way to make it work, it will be break again soon. Any update of nextjs (major|minor|patch) - expect to spend 6 weeks trying to make things work again, every time. Assume that is your baseline reality

[lukovskij]

@ScriptedAlchemy thanks! Will we encounter any issues using the @module-federation/enhanced/runtime package solely for runtime in a Next.js host application, loading components only on the client side? We don’t intend to use Module Federation during the build phase and will be loading remote components from a non-Next.js app (runtime only).

[alexandresgraca]

You could add Nuxt support, there is already a working vite-federation-plugin, but still no Module Federation with SSR support for Nuxt apps. Especially when a Nuxt app is a remote is quite tricky.

[ScriptedAlchemy]

Module-federation/vite is the official plugin from us. Any others will not be based on the v2 runtime design and thus incompatible with this entire ecosystem.

Nuxt must work with ssr to be considered a alternative imo, otherwise its in the same category as CRA.

If you use rspack + nuxt however, SSR should work, so ill try that

[papers156]

Can you expand on Pages Router will remain "supported," If using page router is nextjs-mf a reliable and supported plug in?

[ScriptedAlchemy]

Can you expand on Pages Router will remain "supported," If using page router is nextjs-mf a reliable and supported plug in?

Whatever works today will continue to work until it doesn’t, if vercel ships an update that break the plugin again, and it's not a quick fix, it won't be fixed.

I will ensure the current CI tests pass. If we make a change to federation, the plugin will still get an update in order to make CI tests pass.

Nextjs-mf will receive no new features or development from the core team, beyond making CI green in day to day development.

In 2026, we will begin disconnecting its unit tests from CI and no longer track if it works with our ecosystem updates. Assuming someone in the community does not take over maintenance-expect it to be abandoned in the second half of 2026

[Hareesh108]

Hi Zach, what alternative frameworks do you suggest?

ModernJS will be the best for federation since it's a first-class feature and supports ssr etc.

Otherwise, anything that isn't owned and operated by vercel should be substantially better. Next has worst support, least features, most problems.

TanStack ModernJS Remix Nuxt Rsbuild The Boring Stack Vite based apps, but no ssr or typescript support.

Hii @ScriptedAlchemy, Is there any other way to do it in the next js?

Please, give some suggestions.

[ScriptedAlchemy]

The following options:

• Use module-federation/runtime without any compiler plugin.
• contact vercel
• remain on whatever the last version of next.js exists where the plugin still works and never update again
• take over my role as primary maintainer of the next plugin.

Iframe is a great option for next.js as well

Id definitely suggest contacting vercel or opening git issues there. It's out of my control

[prakashmallow]

@ScriptedAlchemy Could you please provide the steps for migrating from Next.js to React using module federation?

[ScriptedAlchemy]

Whats react.js? Like a CSR app? like CRA or rsbuild react SPA?

[prakashmallow]

@ScriptedAlchemy Like React CSR app

[ScriptedAlchemy]

Rsbuild.dev has some great guides. What exactly are you looking for?
In my mind, I'm thinking of copying and pasting the code over and replacing the data loading with something else. 🤔 I don't think a guide is needed for that.

Is there something I am missing?

[fcano-ut]

Hi @ScriptedAlchemy. Thanks for the support you provided so far, I understand the decision.

We have a small Next.js host app we just released to production, and we could consider in our plans to use Remix or other alternative other than Next.js. However, I wanted to get some clarification on this alternative to see if there's a workaround:

Use module-federation/runtime without any compiler plugin.

With that solution, we cannot share dependencies, right? Let's say the host app loads React 18 and a micro-frontend uses React 18, the client would need to download it again?

(So we'd just be using Module Federation as a glorified way of loading JavaScript from another domain, which beats the point in my opinion)

Is my assumption right, or can federation runtime share dependencies as well?

Note: we're only using Next.js for the host, all micro-frontends are static (create-react-app basically)

Thanks 🙏

[ScriptedAlchemy]

https://module-federation.io/guide/basic/runtime.html#init

Runtime can provide shares to remotes

If you are using something like cra, consider rsbuild.dev 🥰

[zackarychapple]

Today I had a fantastic conversation with @anthonyshew and @mknichel. We talked a good bit about Module Federation support for both Turbopack as well as NextJS.

While we didn't have any final decisions that are immediately actionable, it did give me enough confidence that there appears to be a path forward now.

Hoping we can get more folks from the MF core team together in early 2025 to really put together a solid path forward.

Since MF and NextJS is very heavily asked for and we have Zephyr Cloud customers asking for it too we have a pretty strong interest in making this happen too.

Stay tuned!

[ScriptedAlchemy]

Today I had a fantastic conversation with @anthonyshew and @mknichel. We talked a good bit about Module Federation support for both Turbopack as well as NextJS.

While we didn't have any final decisions that are immediately actionable, it did give me enough confidence that there appears to be a path forward now.

Hoping we can get more folks from the MF core team together in early 2025 to really put together a solid path forward.

Since MF and NextJS is very heavily asked for and we have Zephyr Cloud customers asking for it too we have a pretty strong interest in making this happen too.

Stay tuned!

Very encouraging - We will have several members on WebInfra in San José early next year.
Im more than happy to work with framework teams who want to see federation on their platforms, if vercel wants to support it - we are happy to adjust federation ecosystem if needed.
Turbopack support should in theory not be too painful to support, as with Rspack we minimized the amount of Rust code required so that we can better maintain what need be on the runtime side and reduce the maintenance overhead.

Regarding app router, it would be possible to support - the main blocker resides in webpack (since we forked out of webpack, perhaps in ehnanced package now) where layers is not considered with ProvideShare/ConsumeShare is creating the module, so only 1 react is created which works either on page router or app router, whereas we need 2 "react", and "(rsc)react" which resolve to different modules.
Alternatively, share.react.layer may be a better options, similar to how share scope works.

Pages router is quite "trivial" to support from inside next.js - from the outside, not so much (hence the planned retirement of this plugin)