#Usando Nx CLI for React

#Scaffold o Shell (Host) aplicação

Let's crie uma shell chamada shop no apps/ diretório com remotes chamada products, cart e checkout.

npx nx g @nx/react:host apps/shop --remotes=products,cart,checkout

Você'll notice four aplicações have been generated no apps/ diretório. At este point, everything é generated e configured correctly.

Note: Nx will configure the routing between the shell and the remote applications, as well as attaching each remote aplicação to the shell in the module-federation.config.ts file to inform Module Federation of the remotes.

#Serving your Module Federation configuração

Nx employs several techniques quando working com Module Federation para garantir uma great developer experience (DX), performance e scalability. Once such technique involves apenas serving remotes esse você're actively working com arquivo watching attached. In Nx, these são chamada dev remotes. O other projetos são built by Nx e served statically via http-server. Esses são chamada static remotes.

Note: A bonus benefit of using Nx with Static Remotes comes from Nx Caching. Any remote that you have not changed, will be restored from cache and served, reducing compute overhead.

To serve your shell com all remotes treated as Static Remotes, run:

npx nx serve shop

Você'll now ser able para acessar shop on localhost:4200 e você pode navigate entre a aplicação remotes usando o links at o top do page.

Quando você're actively working on uma aplicação remote (uma Dev Remote), você pode pass o --devRemotes flag para inform Nx para usar @rspack/dev-server para serve a aplicação remote, allowing for HMR e arquivo watching.

npx nx serve shop --devRemotes=products

Now, se você make changes para your products aplicação, they vai ser reflected no shell aplicação no navegador.

Note: To learn more about why Nx recommends serving everything, read here.

#Building your Module Federation configuração

Nx cares uma lot about performance e DX, especialmente em monorepos. It offers você uma comando esse vai let você build everything at once. Helpful for full redeployments de all projetos no Module Federation system.

npx nx run-many -t build

Quando running este comando, se Nx detects uma projeto did não change, it vai restore o cached build artifact for esse projeto instead de rebuilding it. However, sometimes este é still overkill. Portanto, para apenas rebuild o projetos esse have actually been changed, e cut down any additional time spent restoring cached build artifacts, Nx offers uma comando para apenas recompute affected projetos.

npx nx affected -t build

Você pode view o build artifacts at dist/apps.

#Scaffold novo Remote aplicação

Let's add uma nova remote chamada login e attach it para our shop shell.

npx nx g @nx/react:remote apps/login --host=shop

It's esse simple. Se nós run npx nx serve shop --devRemotes, nós pode now continue desenvolvimento no login remote e see it reflected no navegador.

#Remotes

O remotes opção gives você two opções for defining aplicação remotes usado pelo shell (host).

Você pode forneça um array de Nx projeto names, ou uma tuple, defining o Nx projeto name, e o entry location para o remote.

remotes: ["products", ["cart", "http://my-live-cart.myapp.com/mf-manifest.json"]]

Under o hood, Nx vai parse it's Project Graph para discover information around o entry location do remote projeto e configure o ModuleFederationPlugin accordingly. Este é também usado para serve o Module Federation configuração quando você run npx nx serve shop.

#Expõe

O exposes opção matches o exposes opção no ModuleFederationPlugin e fornece você o ability para specify que módulos deve ser federated por uma aplicação remote.

#Shared

Nx vai use its projeto graph para determine all o dependências (npm e local) esse são usado pelo projetos no Module Federation configuração. It vai then compartilhe all these dependências at o detected versão as singletons. Este é great for getting up e running quickly, but sometimes, você precisa control este behaviour. O shared opção allows você para pass uma função onde você pode write custom logic para determine como uma dependência deve ser shared.

// do not share lodash to allow better tree-shaking
shared: function(libraryName, shareConfig) {
  if(libraryName === 'lodash') {
    return false
  }
}