Diagnostiquer un monorepo npm : deux applications et un paquet partagé

Une application React peut importer du code situé hors de son propre dossier. Dans un monorepo, traiter apps/app-a comme un dépôt indépendant peut exclure le lockfile et un paquet voisin. Avant de choisir un hébergement, vérifiez ce que nécessite la construction complète et les fichiers produits par chaque application.

Ce diagnostic utilise un exemple original sous licence MIT : deux frontends React/Vite, Carta del horizonte et Taller de señales, qui importent @hostbrid-demo/shared. L’essai est terminé et reste local. Il ne démontre ni une livraison sur Hostbrid, ni la compatibilité SSR, ni la publication par push, ni la version effective de Node d’une construction du produit.

Conserver la racine qui définit les workspaces

La racine contient package.json, sa déclaration de workspaces et package-lock.json. Les applications se trouvent dans apps/app-a et apps/app-b, le paquet partagé dans packages/shared. Installer depuis la copie complète permet de résoudre ces paquets liés. La documentation npm 10 sur les workspaces décrit des paquets locaux gérés depuis une racine ; cette page correspond à npm 10.9.9, indiqué comme Legacy.

Distinguez le dossier servi au navigateur de celui nécessaire à l’installation et à la construction. Vous pouvez publier une seule sortie sans retirer d’abord les dépendances nécessaires à son build. Ce n’est pas une application React unique avec un seul dist : il y a deux applications, des dépendances voisines et deux artefacts différents.

Construire deux sorties sans mélanger leurs pages

L’essai a utilisé Node 22.23.3 et npm 10.9.9. Le dépôt exige Node 22.23.3 et conserve React 19.3.0 et Vite 8.3.4 dans son lockfile. Exécutez ces commandes depuis une nouvelle copie en conservant la révision du dépôt :

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 vérifie Node puis lance les builds A et B. Pour les sélectionner séparément depuis la même racine, utilisez les scripts npm run build:a et npm run build:b.

La documentation de construction Vite permet de comparer la sortie de votre projet. Publier le dist de A ne publie pas B. Ne réunissez pas leurs deux index.html et ne livrez pas node_modules comme un artefact statique.

Vérifier aussi la pièce partagée

Les deux applications importent l’illustration de packages/shared/horizon.svg. L’exemple emploie une référence statique new URL('./horizon.svg', import.meta.url) et conserve un fichier SVG avec assetsInlineLimit: 0. Les neuf tests ont vérifié que les deux sorties préservent ses octets d’origine, ainsi que le marqueur partagé, les titres et les ressources résolubles.

Une question sur plusieurs répertoires publics dans un monorepo illustre cette difficulté d’organisation des ressources. Elle ne démontre pas qu’un plugin soit nécessaire et ne remplace pas l’examen des fichiers produits.

Ce que l’essai local a rejeté

Le contrôle négatif a conservé uniquement apps/app-a, excluant le lockfile racine et le paquet partagé. npm ci s’est terminé avec le code 1 et EUSAGE, faute de lockfile, avant la résolution des dépendances. Cela ne démontre pas qu’un import de shared était la première erreur : l’installation n’a jamais atteint cette étape.

La copie complète a réussi l’installation, la construction et neuf tests Node. L’essai distinct a vérifié huit cas Chrome : accueil et page intérieure de chaque application à 390 et 1280 pixels, DPR 2. Le SVG s’est chargé sur les deux accueils ; la sélection n’existait qu’en mémoire du navigateur et se réinitialisait au rechargement. Quatre contrôles HTTP ont renvoyé 404 pour les routes et SVG absents, un de chaque par application.

npm test reproduit les neuf tests de fichiers du dépôt ; il ne lance pas automatiquement ces huit cas Chrome. En servant chaque sortie, vérifiez l’identité des pages, l’accès direct, le rechargement, les ressources et les erreurs réelles. Un 200 avec la mauvaise page d’accueil ne démontre pas une route correcte.

Avant de choisir Projects

Le résultat identifie les dépendances et artefacts locaux. Si vous envisagez Projects, confirmez la compatibilité des commandes, l’accès au dépôt, la capacité disponible et la version effective de Node avant de souscrire ou de créer un projet. Cette livraison sur le produit, le HTTPS public, le SSR et un backend n’ont pas été testés. Gardez un inventaire distinct des services et des données ; ces deux dossiers dist ne les déplacent pas.