Disable the Module federation extension in production environment

[snaumov]

Is there a way to block the chrome extension proxying capability in the production-like environment?

Use case - the developers might start using the extension to debug production environments with their local builds of a frontend app, making it potentially easier to inadvertently break those environments

[zackarychapple]

@snaumov the extension is not actually changing the configuration on the server itself for the entire environment. I believe that its only changing for their local user.

[snaumov]

For sure. In our organization, I'm on a platform team, and we've been using Module Federation on our project for about four years. We built our own version of DevTools that allows overriding federated modules—not as a Chrome extension, but as a React app embedded into our main web app. We also deliberately chose to disable the DevTools in any production or shared environments.

We recently upgraded to MF 2.0 and discovered the extension, which we really liked. However, we also realized that it allows overriding federated modules in any environment (in the user’s browser, not on the server).

In the past, we've received requests from product teams asking why our DevTools are disabled in shared environments. Our typical response has been that shared environments should be the "source of truth" for the current state of the codebase and shouldn't be overridden with personal or preview branches.

Our immediate concern is that developers might develop the habit of:

• Debugging production issues using their local builds of the app, forgetting to clean up the proxy module configuration, and unintentionally causing unexpected server writes via the API.
• Sharing preview branches with peers or product teams (along with instructions on how to use the extension to override modules), potentially leading to server-side issues due to unintended API calls.

Additionally, the Chrome extension preserves the proxy configuration, meaning that the next time a user visits the page, the overridden module will still be applied. This increases the risk of people forgetting they are using a local or preview build of the web app.

[zackarychapple]

Ah, this is actually something that we do and find folks really love with Zephyr, but that could be messier without the infrastructure part we have behind it to manage those versions and environments. Sounds like something that would be helpful to disable then. I'll leave this open for the team to pick up.