> I still don't see how this is going to work > when the shared modules release breaking changes The team I'm working on is currently working on such an appl

> I still don't see how this is going to work > when the shared modules release breaking changes The team I'm working on is currently working on such an application, and that problem is the one I've been worried about most. What do we do when there is a major version breaking-change upgrade of the shared design system? If you are working within a singular repository (monorepo), you can make a singular commit that fixes all parts of your application at once, and since it is deployed in one go there will be no breakage in production. On the other hand, if you have a shared library that affects multiple repositories, somehow everybody needs to do the PR at the same time, and somehow every deploy needs to be synchronised in order that all micro frontends are updated at the same time. How can that be done in a way which doesn't cause breakages? What if one team is slower to update than every other team? What crazy piece of infrastructure might we require for this kind of gradual distributed upgrade? This almost certainly sounds crazy to most engineers, but at the organisation I work they build quite a lot of App Store style applications which amalgamate 100s of other applications into one gigantic application. Additionally, for some legacy reason, we are tied into using separate repositories for each line-of-business micro frontend.