pure scss/css lib not recognized by share scope

[YanPes]

Hi guys,

our Module Federation ecosystem shares some Styleguide related libraries with the MF ShareScope. It works fine for component libraries but we face an issue with a pure scss/css library (defines basic resets, generic styleguide definitions, etc.).

Adding the lib to the share scope was the initial go-to implementation but the lib does not show up in the actual runtime sharedMap of the remote/host.

This generates an issue since each application in the ecosystem inject the lib when loaded to the runtime resulting in lots of duplicate css definitions in the browser.

Is there a solution for this? All host/remotes work with css modules and proper abstraction -> Works fine. Only the shared lib provides issues since injected on a global level.

[ScriptedAlchemy]

make a js file and import that / share that who imports the styles?
CSS is a side effect of a javascript module.
Also sharing works by seeing what import from exists in the codebase, if it cannot see a import from that matches what the share key or request matcher is, then its ignored / never seen becasue we hook into the module factory phase so we depend on the bundler consuming it to begin with then redirect the module

[YanPes]

Then I must wrap in in JS - I thought there might be a solution/configuration with css natively I am just not familiar with.
Thank you Zack!

[ScriptedAlchemy]

Not that im familiar with as someone needs to import it and mini css isn't a native module, its actually a child compiler that produces a side effect dependency.
I do want to look into a solution here but I fear its tricky as the imports could also be css includes etc which is beyond the sight of normal module factory phases. Does exposing it work? If you expose css file directly what happens?

[YanPes]

The library is imported via npm as a classic node_module since the lib is company global.
I define it in the share config like any other node_module (react, react_dom) but it is totally ignored and not visible in window.__FEDERATION__.__SHARE__ runtime object.
My assumption -> As this is the only lib ONLY containing css / scss files, it is omitted by the process. Other company global libs working with ts or React work just fine in the share scope.

Does exposing it work? -> You mean ditching the node_module, migrating to rslib to use the federated output to be called via federation directly?

[ScriptedAlchemy]

keep it as a node module, just see if exposing it happens to work from someone - for experimentation purposes. You can also try share & expose as well, ive done this before. a few times for other workarounds - might work in this case too. but never tried this with css

[YanPes]

I found a solution that is working for now.
As you know I use a shared remote containing decentral services, stores, brokers etc. I wrapped the css import in JS and exposed it from there.

The host application consumes the remote JS as early as possible. (Modern.js > uppermost layout.tsx, will experiment with custom entry.ts file to inject it outside ReactDOM.render() to doublecheck for optimization in the profiler)

For now, the cascade only shows the imports derived from shared - lovely!

I'll set the shared import as mandatory for applications in the ecosystem with a governance rule. With a boolean value set in the global window object I can then check if the content was already loaded or not to prevent duplicate injection.

Kind of a workaround, but everything else did not cut it so far.