i don't have a solution yet :/

This is a drawback of sharing modules, bigger chunks potentially. But this is also a problem of intrinsic dependency/coupling - technically the remote isn't fully self sustaining. Webpack doesn't know it's missing something - like if you had a react component use context but the host didn't implement it. Component is dependent on the host to have done something. Global css is a similar challenge, since nothing described in the exposed file that said anything about depending on X / it's not accessible during build since we don't know about remotes at build

So, interestingly enough, I don't think I am, unless tailwind does this automatically when injecting styles via the config, I'm going to try implementing the css in the tailwind css file itself and see if that makes a difference, could be it, will also be happy to message you on twitter momentarily.

This is a drawback of sharing modules, bigger chunks potentially. But this is also a problem of intrinsic dependency/coupling - technically the remote isn't fully self sustaining. Webpack doesn't know it's missing something - like if you had a react component use context but the host didn't implement it. Component is dependent on the host to have done something. Global css is a similar challenge, since nothing described in the exposed file that said anything about depending on X / it's not accessible during build since we don't know about remotes at build

This makes sense as the host styles is not able to be called via the remote in another server and the global styles don't inject into the component themselves, but actually just the host, so just explicitly call it instead.

Resolved via import of tailwind module in component, didn't have to adjust config just added:

import 'tailwindcss/tailwind.css in the component versus trying to add global styles to the app.

so:

import 'tailwindcss/tailwind.css'
 const comp = () => (
 // do tailwind stuff here
)
return comp;

Yeah exactly. It's a side effect some other file is adding. Same issue if you put context provider in a parent.

Tailwind auto teee shakes. So you need to opt out of that if you want to implicitly depend

Hi, looking at the answer from @integrate-your-mind and @ScriptedAlchemy, I got a similar approach working in Angular and Nx, this may insterest @Coly010.
Suppose we have a host app loading from a federated components project. Both apps have Tailwind mode: 'jit' enabled.

For each component that needs to be exported, adding

@import 'tailwindcss/tailwind.css';

at the top the component's scss file works.

Of course, there is some duplication, it's not totally optimal. But this is a realistic scenario. The full Tailwind stylesheet for the components mfe is 31kB, loading ~5 components from the project would be ~170kB if all are used. That compared to the 3MB full Tailwind size without optimization seems like a good tradeoff. For the Angular case, I am thinking this could be further optimized by creating an "empty" styles component without ViewEncapsulation, importing as above. Consumers could import it first to load the optimal 34Kb styles once.

I have also contemplated a solution involving Tailwind safelist option, but I'm not so sure how that would exactly work.

Anyway, just some thoughts. This is an interesting problem in general

If this is just browser side problems then it's also an easy fix. I think - it should just mean we need to tell webpack it should hold the promise and load additional chunks.

Very interesting topic.

I used the federated stats plugin to get the chunk mappings in a Node.js app (not Next.js), and I made it work for SSR (add stylesheets, preload assets, etc.).

But keeping chunk mappings in sync with the loaded module can be a bit challenging.
First, the federated module should expose this mapping somehow (it can be just a file in a CDN). Then, at some point, the server should fetch the mappings (at bootstrap time, on render, etc.). And finally, use a revalidation strategy for your federated modules and fetch chunk mappings for those that changed.

This process requires some tuning and adds some extra network calls.

I agree with this approach as it is more efficient and less error-prone:

...I expose a module at the end of the cycle that adds all the chunk mappings for my remotes. So when I load a federated module, it can look up the styles that should be SSRd as well.

But I'm not 100% sure how to do it. So @ScriptedAlchemy, could you please share those references you mentioned above?

I understand the mechanism to track and expose chunks could be framework agnostic and maybe be part of module-federation/node or another package. Is something related to this on the roadmap?

Well, I realized that in the case of SSR, exposing chunk mappings is not as straightforward as I thought.

When building the federated module for SSR, you run Webpack for browser and server targets, so you could get two different sets of chunks. Then, in the SSR phase, you use the federated module compiled for the server to render, but the chunks you want to know are the ones for the federated module compiled for the browser.

I think is feasible to add the browser chunk mapping to the federated module for the server, but it adds some constraints to the build as the server build will depend on the client build to get the stats and use it for the chunk mapping. So maybe there is a better way.

Server build already depends on client build at least in next apps. So this is a commons case.

You could also inject the manifest into the remote at the top after the builds both run.

Nextjs-SSR has my old flushing mechanism. It needs to be rewritten and implemented into nextmf. That's the last remaining feature.

Outside of next, it's a similar process but I'd have to make it be a little sdk or api so devs could wire it to whatever tool they use.

@apehead dm me on twitter- if you're interested I'd love some extra minds thinking about this. I can make it work but I'm looking for better implementations and my correlation algorithms are a little flaky.

One idea I had was during chunk load on server I could push the browser chunk id into a Map then flush it out at the end of the render.

I'd need to track the route since chunks don't load ever time you execute.

Or I could put a generator around the get think of MF api. So whenever the factory is called I push the id into Map

Upon further review, I believe it's related to Tailwind's tree shaking not being able to access the logic from the UI Library so classes aren't being generated.

any solution for tailwind and nextjs?

For Tailwind, use the allowlist with a wide regex so it doesn't remove styles. Essentially, disable tree-shaking of Tailwind.