Is it bad to use singleton everywhere? about universe HOT 6 CLOSED

Guys, Hi! I apologize for reopening this question, but I have a slightly different case and I can't find recommendations about this anywhere. In my project we use MF, but we don't use a monorepo. There is a host application, and there are N remote applications that are loaded on the page of the host application. And I have a question about using singleton for shared dependencies. Obviously for dependencies like React, React DOM etc we have to use singleton for the application to work correctly. But besides these dependencies, I also have such dependencies as styled-components, @reduxjs/toolkit, @tanstack/react-query and so on, and I have a question about using the singleton flag for them: if we use the singleton flag for all dependencies, then how to build a flow of updating shared dependencies in applications in this case?

What is the point: if we use singleton, then if one team updates for example styled-components (major version), they will fail and will not work, because the version of the host application will be used (well, or for example the version of styled-components from another remote application loaded earlier than the current one). If we don't use singleton, then in case of requiredVersion mismatch (with strictVersion disabled) MF will simply load the second version of styled-components on the page, the only question left is whether a certain library will be (in our case styled-components) work correctly in two instances of different versions on the page.

In general, the question is: should we use singleton for all shared dependencies in this case or not? It seems to me that singleton is a strict restriction for those dependencies that in principle cannot work on the page in several instances of different versions, because even without singleton if the version of the library is correct, the already loaded version will be used, if it is available. So in this case we don't lose in performance (we don't load unnecessary modules without actual need).

Could you please share your opinion on this issue? @ScriptedAlchemy 🙏

from universe.

I've used federation a good amount and I'd personally recommend defaulting to sharing everything as a singleton.

I just don't think it's safe to assume that people are writing code in a non-singleton way, especially related to React.

It's awesome that federation can support multiple implementations of modules but it feels like something you'll want to opt-in to. Whether it's never sharing or it's version-based sharing.

from universe.

Ill second that.
If you work somewhere where the codebase isn't a complete shitshow, and can actually keep deps aligned - then id suggest it. It can reduce whats downloaded and so on.

You could say singleton by default and make the users have to opt out case by case, this would improve general alignment - similar to how nx and rush really dont like multi versions of same package installed in monorepo

from universe.

Singleton by default and make the users have to opt-out case by case

Really makes sense, thank you for your answers

from universe.

I had the same thoughts @D9RS. I'd love to hear if you've learned anything new since you posted your comment.

from universe.

@D9RS use singleton on things that need react context or singleton context, like a provider or redux

Singleton for all shared packages will probably break something when major version is a issue on a library

from universe.