Diagnosticar un monorepo npm: dos aplicaciones y un paquete compartido

Una aplicación React puede importar código que no está dentro de su propia carpeta. En un monorepo, elegir apps/app-a como si fuera un repositorio independiente puede dejar fuera el lockfile y un paquete hermano. Antes de elegir alojamiento, comprueba qué necesita la construcción completa y qué archivos produce cada aplicación.

Este diagnóstico utiliza un ejemplo original MIT: dos frontends React/Vite, Carta del horizonte y Taller de señales, que importan @hostbrid-demo/shared. El ensayo está cerrado y es local. No demuestra una entrega en Hostbrid, compatibilidad SSR, publicación por push ni la versión efectiva de Node de una construcción del producto.

Conserva la raíz que define los workspaces

La raíz contiene package.json, su declaración de workspaces y package-lock.json. Las aplicaciones viven en apps/app-a y apps/app-b; el paquete compartido, en packages/shared. Instalar desde la copia completa permite resolver esos paquetes relacionados. La documentación de npm 10 sobre workspaces describe ese conjunto de paquetes locales gestionados desde una raíz; la página corresponde a npm 10.9.9, marcado como Legacy.

No confundas la carpeta que entrega archivos al navegador con la que necesitas para instalar y construir. Aquí puedes publicar sólo una salida sin recortar primero las dependencias que su build necesita. No se trata de una única aplicación React con un solo dist: hay dos aplicaciones, dependencias hermanas y dos artefactos diferentes.

Construye dos salidas sin mezclar sus páginas

El ensayo utilizó Node 22.23.3 y npm 10.9.9. El repositorio exige Node 22.23.3 y conserva React 19.3.0 y Vite 8.3.4 en el lockfile. Ejecuta estos comandos desde una copia nueva y conserva la revisión del recurso:

git clone https://github.com/ocentelles/hostbrid-example-monorepo.git
cd hostbrid-example-monorepo
git checkout bb4c01995cea57f56fcc72af8b02e70126edbf80
node --version
npm --version
npm ci
npm run build
npm test

npm run build comprueba Node y ejecuta los builds A y B. Para seleccionarlos por separado desde la misma raíz, los scripts son npm run build:a y npm run build:b.

La documentación de Vite sobre construcción sirve para contrastar la salida de tu proyecto. Publicar una carpeta dist de A no publica B. No combines sus dos index.html ni entregues node_modules como si fuera el artefacto estático.

Comprueba también la pieza compartida

Ambas aplicaciones importan la ilustración de packages/shared/horizon.svg. El ejemplo usa una referencia estática new URL('./horizon.svg', import.meta.url) y mantiene el SVG como archivo con assetsInlineLimit: 0. Las nueve pruebas verificaron que ambas salidas conservan sus bytes originales, además del marcador compartido, títulos y assets resolubles.

Una consulta sobre varios directorios públicos en un monorepo muestra esa fricción al organizar assets. No demuestra que necesites un plugin ni sustituye comprobar qué archivos produce tu implementación.

Qué rechazó el ensayo local

El control negativo conservó sólo apps/app-a, dejando fuera el lockfile raíz y el paquete compartido. npm ci terminó con código 1 y EUSAGE porque faltaba el lockfile, antes de resolver dependencias. Ese resultado no prueba que el primer fallo fuese un import roto de shared: la instalación ni siquiera llegó a esa fase.

La copia completa pasó instalación, construcción y nueve pruebas Node. El ensayo separado comprobó ocho casos Chrome: portada y página interior de cada app, a 390 y 1280 píxeles, DPR 2. El SVG cargó en ambas portadas; el estado de selección era sólo memoria del navegador y se reinició al recargar. Cuatro controles HTTP devolvieron 404 para ruta y SVG inexistentes, uno de cada por aplicación.

npm test reproduce las nueve pruebas de archivos del repositorio; no ejecuta automáticamente aquellos ocho casos Chrome. Al servir cada salida, verifica la identidad de sus páginas, entrada directa, recarga, assets y errores reales. Un 200 con la portada equivocada no demuestra una ruta correcta.

Antes de elegir Projects

El resultado permite identificar dependencias y artefactos locales. Si valoras Projects, confirma compatibilidad de los comandos, acceso al repositorio, capacidad disponible y versión efectiva de Node antes de contratar o crear un proyecto. No se ha probado esta entrega en el producto, HTTPS público, SSR ni un backend. Conserva un inventario aparte de servicios y datos; estos dos dist no los trasladan.