Module Federation host build failing due to remote error about nx

[ndcunningham]

This is intended.
If you want your shell to be built standalone you would have to change your remote declaration:

  remotes: ['app1'],

To use something like promise-based remotes where the remote is only known at run-time.

Changing back to use remote.d.ts just removes the type safety that was added.
So instead of getting the error at build time, you would get it at run time.

When you generate a host you can pass the --dynamic flag for this to be set up. However, since the remote deployment can be customized we leave that implementation up to you.

npx nx generate @nx/react:host host \
--dynamic true \
--remotes myremote

[bouncehead13]

Thank for getting back to me @ndcunningham! Maybe I didn't explain well our use-case and the problem Nx introduced.

So this is a monorepo and we could have different teams owning different portions of the site, but all "links" known during build time. Say Team A manages the host/shell application while Team B manages a singular remote app1. However, the individual team should be able to deploy separately. Meaning as Team A makes updates to the Shell and deploys, Team B could be "breaking" their code but a week out from deploying. Still Team A can go live with their modifications.

You're suggesting in this case, rather than having Shell know about App1 during build time (aka the known remote entry file location), make it known during run time with dynamic imports.

So it's a conciseness design and not a bundler defect that all remotes are "built" when the Shell/Host gets built? Seems like an anti-pattern of MFE.

[Coly010]

@bouncehead13 Not necessarily an anti pattern.

MFE is just a general term used for a technique that involves loading certain portions of the frontend application remotely.
It could be iframes for example.

What we have learned over the years of supporting MFE architectures boils down to two main use cases:

1. Faster builds
2. Independent Deployability

We optimized what we generate out of the box for faster builds, as that was the overwhelming majority of why people were reaching for MFE.

If your use case is Independent Deployability then you can still achieve it along with type safety.

1. Make sure there are no implicitDependencies in your host’s project.json file.
2. Add // nx-ignore-next-line above the imports in your host for the remotes (this will remove any edge created in the project graph between the two projects)

With that being said, we would still recommend that if you redeploy your host/shell application, that you should redeploy all your remote applications.

Your shell may have bumped a version of a package that your already-deployed remotes also used, and now that package can no longer be shared. This holds true also for workspace libraries, wherein you could break singletons. I.e if you rely on a singleton source for application state shared across remotes, then you could introduce a runtime-only breaking change.

Whereas redeploying everything when shell is changed helps prevent these potential issues at runtime.

We would also recommend for general development practice that your applications should always be in a deployable state (even if it’s an old state, this could mean feature branches for individual remotes, or using a feature flag setup) when working with MFEs.

This also helps ease the deployment burden by knowing that you can always deploy everything without breaking production.

For example, if a security vulnerability was found in a package that all your host and remotes use, and you need to release a hot fix immediately to patch that vulnerability, it’s a simple case of adding the patch and redeploying everything.

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.