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

I currently have no concrete information regarding this, however my previous statements about it looking like it was just an update to next zones was incorrect.

This is the most recent information: "We did do some upgrades to zones and, independently, RSC Federation and module federation are on our minds (though we don't have anything actionable yet). Two different solutions, two different problem spaces."

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 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)

[ScriptedAlchemy]

Update, i think i have found the problem area of layers the problem seems that the layer information is not passed since share plugin is just a path, What needs to happen is consumeShare plugin needs to encode its layer information into the virtual module it makes that connects to share scope. For example i need to use issueLayer from the context to create unique module ids for both react and (rsc)react requests based on layer info or issuer layer info.

@anthonyshew and @mknichel - im not sure how familiar you are with webpacks internal apis, but is there any chance Tobias would check the implementation if i add support in a PR for it? (or anyone else who has a similar level of understanding into webpacks api mechanics), I can try the maintainers at the webpack project - but it most defer to me for federation so i do not think there are many maintainers who understand how it works. Outside of myself and tobias, i dont know any other person who knows how it works lol.
The functions i need to update are createConsumeSharedModule, resolveMatchedConfigs(?), normalModuleFactory.hooks.module.tap in provide shared plugin, and provideSharedModule - which in theory should allow layers to work, assuming i do the plumbing of the module and dependency types as well.

After that, i will still need to update some aspects of the runtime so that it understands how to resolve based on package name + version + layer

[sokra]

I guess adding layer support to MF could make sense.

Note there are two sides of shared modules: the module in the compilation, and the module exposed as shared module in the MF offering.

The MF offering side already supports shareScope, which allows to scope shared modules. So that would be the "layer" concept on that side.

But one can't specify a layer of the module in the compilation. We would need to add this option.

Note that layer and scopeShope doesn't need to have the same value. You could map a module from layer abc to scopeScope def if you want to.

Ping @mknichel if you have something to review.

[ScriptedAlchemy]

@sokra thanks for joining in here. I thought about share scope which would work - but it's the loader layer or issuer layer which needs a way to be specified so resolve and transform follow the rules.

My idea was to add another option to share / expose. Since Module class super() accepts a 3rd argument which is layer. I could easily have the module factories add it with another arg.

Next.js is the primary example of which case. Consume and provide shared module. Along with exposed would need layer to be added. Which i can do

• but would next be willing to support the transform without issuerLayer as well since MF won't have an issuer? If so I'll make the layer changes needed i have done about 50% of the update already- mostly focusing on shared

Again, really great to see you again 🥰 not many people i can talk to who understand these days, thanks man.

I'll continue my work on layers and tag those you mentioned

[anthonyshew]

Sidebar: Someone sent me this Issue yesterday and they were confused by the Regarding "RSC Federation" Tweeted by Vercel section. RSC Federation isn't Multi-Zones. Is it possible to get that updated for clarity that that isn't the case, @ScriptedAlchemy? 🙏

Sidebar to the sidebar: My GitHub notifications are a mess so I apologize in advance if I miss a tag. I only saw these because the aforementioned someone linking me here.

[ScriptedAlchemy]

Yes, do you have a more accurate piece of information that I can amend it to?

The last I heard was that it looked more or less like an upgrade to zones. Are there any specifics around it or a general direction?

• could someone import from something like header?
• will it cause page reload to hop routes?
• would client components work?
• is it more akin to merging RSC dom encoded payloads from multiple servers over stream?

Happy to correct. Will strike through in the meantime

[anthonyshew]

Copying over from our DM's (thank you).

It's moreso just that they're two separate things. We did do some upgrades to zones and, independently, RSC Federation and module federation are on our minds (though we don't have anything actionable yet). Two different solutions, two different problem spaces.

[ScriptedAlchemy]

@sokra @mknichel - I have opened a pull-request for the first part, would you prefer i ping you with each step updated, or collect it into a massive pr and ping you then?

Here is the PR for ConsumeSharedPlugin: #3276

[FixDev]

Hi zack @ScriptedAlchemy i still using module federation with next-mf, i used next.js 13, if i don't upgrade the version of next.js the module federation still can be use with no problem?

[ScriptedAlchemy]

Hi zack @ScriptedAlchemy i still using module federation with next-mf, i used next.js 13, if i don't upgrade the version of next.js the module federation still can be use with no problem?

If it works now. It'll probably keep working.
Should be fine.

[ScriptedAlchemy]

@sokra @mknichel i have opened another PR addressing the review comments of 3276; #3307

[AtnasDev]

Hi @ScriptedAlchemy .
First of all this is an absolutely great thread to be reading through 🙏

At our company we are about to setup a new product and we are very inclined to use ModuleFederation for our microFE setup. Furthermore, as many other, we are getting fairly hooked on NextJS as the framework of use. I know that this is likely a not functional direction but I wish to state our composition and pick your brain a bit nonetheless.

We will be setting up a host app preferably using NextJS as the shell which dynamically will import the other applications written in React.
The host will work as the sole application which the user interacts with and therefore contain all routing, shared/global state management and template components.

Each microFE will act sort of a component/feature library themselves and expose content in terms of widgets or smaller components with isolated responsibilities.

This will allow us to setup feature based teams and ensure that the general layout and user journey is maintained in 1 single application, the host.

Do you see this being possible to setup using ModuleFederation, likely with NX in a monorepo structure such as follows

frontend-monorepo/
- host/ (NextJS)
- apps/
|- feature1/ (React)
|- feature2/ (React)
|- ...
- libraries/
|- uiComponents/
|- apiWrappers/
|- ...
- configs...

Alternatively we'll place the host app alongside the other applications as such...

frontend-monorepo/
- apps/
|- _host/ (NextJS)
|- feature1/ (React)
|- feature2/ (React)
|- ...
- libraries/
|- uiComponents/
|- apiWrappers/
|- ...
- configs...

[zackarychapple]

Hi @ScriptedAlchemy . First of all this is an absolutely great thread to be reading through 🙏

At our company we are about to setup a new product and we are very inclined to use ModuleFederation for our microFE setup. Furthermore, as many other, we are getting fairly hooked on NextJS as the framework of use. I know that this is likely a not functional direction but I wish to state our composition and pick your brain a bit nonetheless.

We will be setting up a host app preferably using NextJS as the shell which dynamically will import the other applications written in React. The host will work as the sole application which the user interacts with and therefore contain all routing, shared/global state management and template components.

Each microFE will act sort of a component/feature library themselves and expose content in terms of widgets or smaller components with isolated responsibilities.

This will allow us to setup feature based teams and ensure that the general layout and user journey is maintained in 1 single application, the host.

Do you see this being possible to setup using ModuleFederation, likely with NX in a monorepo structure such as follows

frontend-monorepo/
- host/ (NextJS)
- apps/
|- feature1/ (React)
|- feature2/ (React)
|- ...
- libraries/
|- uiComponents/
|- apiWrappers/
|- ...
- configs...

Alternatively we'll place the host app alongside the other applications as such...

frontend-monorepo/
- apps/
|- _host/ (NextJS)
|- feature1/ (React)
|- feature2/ (React)
|- ...
- libraries/
|- uiComponents/
|- apiWrappers/
|- ...
- configs...

@AtnasDev happy to chat through it with you, shoot me a DM on X or LinkedIn.