How to use the "useIn" option of Federation Runtime?

[fcano-ut]

When registering a micro-frontend or host app using Module Federation Runtime, we can specify a shared object. One of the keys of that object is the useIn key.

The documentation mentions this about that option: "Which modules are currently consuming this dependency".

However for me it's not very clear:

• Should I list the micro-frontends that use this dependency? (what if I don't know?)
• Should I list other dependencies that have this module as a dependency or as a peerDependency? (eg. if I share "react-dom" should I say usedIn: ['react']?)
• Something else?

I could not find any single code reference of that option being used (besides text fixtures of module federation itself).

I and currently finding a bug where shared dependencies are always downloaded (even if they're in a standalone chunk) when the host uses Federation Runtime, and I wanted to discard that I'm not missing any option...

[ScriptedAlchemy]

useIn is not something end users can utilize, its read only information that the runtime reports, as far as i know.

[fcano-ut]

Thanks for the answer, now I'm re-reading the documentation and it's actually correct, I just got a bit confused by the location of some types. Sorry, my fault 🙇

I opened a PR to try and explain what would probably have avoided my confusion: having the Share type next to the loadShare function where it's actually used, and not next to the init function 🤔
(I also did a small fix in the type of init since I was at it)
#3357

[fcano-ut]

Unrelated but:

I and currently finding a bug where shared dependencies are always downloaded (even if they're in a standalone chunk) when the host uses Federation Runtime, and I wanted to discard that I'm not missing any option...

This was also my fault and not related to the usedIn option! I was using different shareKeys in the host and remote.

And another unrelated thing, but let me give you some positive feedback, the runtime plugin is great for us! I'm loving the flexibility it brings us to not be tied to a specific framework, and for us the limitations it has doesn't represent big issues in this particular app. We're using it in the Next.js (using app router) but we are able to keep code compatible with any framework that supports RSC.
I'm loving how the ecosystem is evolving to support multiple bundlers and options like runtime. When we decided to go all-in with Module Federation about two years ago, the limitation to only be able to use webpack was a big drawback. We're finally able to lift that limitation 😃

Thanks for the all the great work!