Trois applications web, pas une avec branchement par rôle

Pas une application, trois applications React 19 + Vite : web (public, les gens qui naviguent), admin (personnel de l'organisation), super-admin (opérations à l'échelle de la plateforme). Chacune est une application déployable vraiment séparée avec ses propres routes, build et port, partageant du code par des paquets de workspace plutôt qu'une application géante avec du branchement par rôle.

Une seule application avec des if (role === "admin") éparpillés a tendance à devenir un enchevêtrement où chaque page tient compte de chaque rôle, la taille du bundle enfle avec du code dont la plupart des utilisateurs n'ont jamais besoin, et un bug dans une logique réservée aux admins met en danger l'expérience publique. Des applications séparées font que web ne livre aucun code d'admin, que le bundle d'admin ne porte pas les pages marketing, et qu'un déploiement d'admin cassé ne touche pas la disponibilité de web.

Frontend/
  apps/{web,admin,super-admin,mobile}/
  packages/
    types/     # types TS partagés
    api/       # client d'API partagé
    hooks/     # hooks React partagés
    ui-web/    # couche shadcn/ui partagée

Les trois applications importent des paquets partagés plutôt que chacune ne réimplémente son propre client. C'est ce qui empêche un changement d'API back-end de dériver silencieusement hors de synchro entre trois front-ends maintenus séparément.

Les deux pièges

L'ordre de build. Les applications dépendent des paquets, donc ceux-ci doivent se construire d'abord ou les applications importent une sortie compilée périmée ou manquante.

pnpm --filter @app/types build
pnpm --filter @app/api build
pnpm --filter @app/hooks build
pnpm build

Cette séquence exacte est dans la CI explicitement — s'y tromper apparaît comme des bugs déroutants « type non trouvé » ou de comportement périmé sans rapport avec ce qui vient réellement d'être changé.

La version dev-local du même piège : éditer un paquet partagé et ne pas le reconstruire signifie que chaque application qui l'importe continue de faire tourner l'ancienne sortie compilée. Un vrai correctif a l'air invisible dans chaque application jusqu'à ce que le paquet ait sa propre étape de build — le fichier source est correct, le comportement ne change pas, et ce n'est vraiment pas évident pourquoi jusqu'à ce que tu t'en souviennes.

Chaque application a aussi besoin de sa propre variable d'environnement de base-URL qui pointe vers le bon back-end. Avec trois front-ends déployés séparément, une variable mal configurée dans une seule apparaît comme « admin ne peut pas atteindre l'API » pendant que web marche bien — déroutant à moins que la config d'environnement par application ne soit la première chose que tu vérifies.