#Usar Nx CLI con React

#Crear la aplicación shell (host)

Vamos a crear un shell llamado shop en el directorio apps/ con los remotes products, cart y checkout.

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

Verás que se han generado cuatro aplicaciones en el directorio apps/. En este punto, todo está generado y configurado correctamente.

Nota: Nx configurará el enrutamiento entre el shell y las aplicaciones remote, y además vinculará cada aplicación remote al shell en el archivo module-federation.config.ts para informar a Module Federation de los remotes.

#Servir tu configuración de Module Federation

Nx emplea varias técnicas al trabajar con Module Federation para garantizar una gran experiencia de desarrollo (DX), rendimiento y escalabilidad. Una de esas técnicas consiste en servir con observación de archivos solo los remotes en los que estás trabajando activamente. En Nx, se llaman dev remotes. Nx hace el build del resto de proyectos y los sirve de forma estática mediante http-server. Se llaman static remotes.

Nota: Una ventaja adicional de usar Nx con static remotes es la caché de Nx. Cualquier remote que no hayas modificado se restaurará desde la caché y se servirá, lo que reduce la carga de cómputo.

Para servir tu shell con todos los remotes tratados como static remotes, ejecuta:

npx nx serve shop

Ahora podrás acceder a shop en localhost:4200 y navegar entre las aplicaciones remote usando los enlaces de la parte superior de la página.

Cuando estés trabajando activamente en una aplicación remote (un dev remote), puedes pasar el flag --devRemotes para indicar a Nx que use @rspack/dev-server para servir la aplicación remote, lo que permite HMR y observación de archivos.

npx nx serve shop --devRemotes=products

Ahora, si haces cambios en tu aplicación products, se reflejarán en la aplicación shell en el navegador.

Nota: Para saber más sobre por qué Nx recomienda servirlo todo, lee aquí.

#Hacer el build de tu configuración de Module Federation

A Nx le importan mucho el rendimiento y la DX, sobre todo en monorepos. Te ofrece un comando para hacer el build de todo a la vez. Resulta útil para redesplegar por completo todos los proyectos del sistema de Module Federation.

npx nx run-many -t build

Al ejecutar este comando, si Nx detecta que un proyecto no ha cambiado, restaurará el artefacto de build en caché de ese proyecto en lugar de volver a compilarlo. Aun así, a veces esto sigue siendo excesivo. Por eso, para recompilar solo los proyectos que realmente han cambiado y ahorrarte el tiempo adicional de restaurar artefactos de build en caché, Nx ofrece un comando que solo recalcula los proyectos afectados.

npx nx affected -t build

Puedes ver los artefactos de build en dist/apps.

#Crear una nueva aplicación remote

Vamos a añadir un nuevo remote llamado login y vincularlo a nuestro shell shop.

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

Así de sencillo. Si ejecutamos npx nx serve shop --devRemotes, podemos seguir desarrollando el remote login y ver los cambios reflejados en el navegador.

#Remotes

La opción remotes te ofrece dos formas de definir las aplicaciones remote que usa el shell (host).

Puedes proporcionar un array de nombres de proyectos de Nx, o una tupla que defina el nombre del proyecto de Nx y la ubicación de entrada del remote.

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

Internamente, Nx analizará su grafo de proyectos para descubrir información sobre la ubicación de entrada del proyecto remote y configurar ModuleFederationPlugin en consecuencia. Esto también se usa para servir la configuración de Module Federation cuando ejecutas npx nx serve shop.

#Exposes

La opción exposes equivale a la opción exposes de ModuleFederationPlugin y te permite especificar qué módulos debe federar una aplicación remote.

#Shared

Nx usará su grafo de proyectos para determinar todas las dependencias (de npm y locales) que usan los proyectos de la configuración de Module Federation. Después, compartirá todas esas dependencias en la versión detectada como singletons. Esto es ideal para ponerse en marcha rápidamente, pero a veces necesitas controlar este comportamiento. La opción shared te permite pasar una función en la que puedes escribir lógica personalizada para determinar cómo debe compartirse una dependencia.

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