Diagnosticar un monorepo npm: dues aplicacions i un paquet compartit

Una aplicació React pot importar codi que no és dins la seva carpeta. En un monorepo, triar apps/app-a com si fos un repositori independent pot deixar fora el lockfile i un paquet germà. Abans de triar allotjament, comprova què necessita la construcció completa i quins fitxers produeix cada aplicació.

Aquest diagnòstic fa servir un exemple original MIT: dos frontends React/Vite, Carta del horizonte i Taller de señales, que importen @hostbrid-demo/shared. L’assaig està tancat i és local. No demostra un lliurament a Hostbrid, compatibilitat SSR, publicació per push ni la versió efectiva de Node d’una construcció del producte.

Conserva l’arrel que defineix els workspaces

L’arrel conté package.json, la declaració de workspaces i package-lock.json. Les aplicacions viuen a apps/app-a i apps/app-b; el paquet compartit, a packages/shared. Instal·lar des de la còpia completa permet resoldre aquests paquets relacionats. La documentació de npm 10 sobre workspaces descriu paquets locals gestionats des d’una arrel; la pàgina correspon a npm 10.9.9, marcat com a Legacy.

No confonguis la carpeta que lliura fitxers al navegador amb la que necessites per instal·lar i construir. Pots publicar una sortida sense retallar primer les dependències que necessita el build. No és una única aplicació React amb un sol dist: hi ha dues aplicacions, dependències germanes i dos artefactes diferents.

Construeix dues sortides sense barrejar-ne les pàgines

L’assaig va utilitzar Node 22.23.3 i npm 10.9.9. El repositori exigeix Node 22.23.3 i conserva React 19.3.0 i Vite 8.3.4 al lockfile. Executa aquestes ordres des d’una còpia nova i conserva la revisió del recurs:

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 comprova Node i executa els builds A i B. Per seleccionar-los per separat des de la mateixa arrel, fes servir els scripts npm run build:a i npm run build:b.

La documentació de construcció de Vite serveix per contrastar la sortida del teu projecte. Publicar el dist d’A no publica B. No combinis els dos index.html ni lliuris node_modules com si fos l’artefacte estàtic.

Comprova també la peça compartida

Totes dues aplicacions importen la il·lustració de packages/shared/horizon.svg. L’exemple fa servir una referència estàtica new URL('./horizon.svg', import.meta.url) i conserva l’SVG com a fitxer amb assetsInlineLimit: 0. Les nou proves van verificar que les dues sortides conserven els bytes originals, a més del marcador compartit, els títols i els assets resolubles.

Una consulta sobre diversos directoris públics en un monorepo mostra aquesta dificultat d’organització dels assets. No demostra que necessitis un plugin ni substitueix comprovar els fitxers que produeix la teva implementació.

Què va rebutjar l’assaig local

El control negatiu va conservar només apps/app-a, deixant fora el lockfile de l’arrel i el paquet compartit. npm ci va acabar amb codi 1 i EUSAGE perquè faltava el lockfile, abans de resoldre dependències. Això no prova que el primer error fos un import trencat de shared: la instal·lació no va arribar a aquella fase.

La còpia completa va superar la instal·lació, la construcció i nou proves Node. L’assaig separat va comprovar vuit casos Chrome: portada i pàgina interior de cada aplicació, a 390 i 1280 píxels, DPR 2. L’SVG es va carregar a les dues portades; l’estat de selecció era només memòria del navegador i es va reiniciar en recarregar. Quatre controls HTTP van retornar 404 per a rutes i SVG inexistents, un de cada per aplicació.

npm test reprodueix les nou proves de fitxers del repositori; no executa automàticament aquells vuit casos Chrome. Quan serveixis cada sortida, verifica la identitat de les pàgines, l’entrada directa, la recàrrega, els assets i els errors reals. Un 200 amb la portada equivocada no demostra una ruta correcta.

Abans de triar Projects

El resultat permet identificar dependències i artefactes locals. Si valores Projects, confirma compatibilitat de les ordres, accés al repositori, capacitat disponible i versió efectiva de Node abans de contractar o crear un projecte. No s’ha provat aquest lliurament al producte, HTTPS públic, SSR ni un backend. Conserva un inventari separat de serveis i dades; aquests dos dist no els traslladen.