Rassemblez tout avec les monorepos

Votre écosystème Angular grandit : une ou deux applications customer-facing, une interface admin, un dashboard pour la direction, un système de ticketing pour le support… et très souvent, toutes ces applications partagent au moins des components UI, parfois même de la logique métier. Pour faciliter la gestion de cet écosystème, je vous propose de découvrir les monorepos.

Qu'est-ce qu'un monorepo ?

Si on prend l'exemple de l'introduction du chapitre, on aurait au moins une library de components UI dont dépendent les applications. On pourrait également avoir une library de formulaires pour les deux applications customer-facing, deux libraries d'authentification (une pour les clients, l'autre pour les collègues), une library pour la gestion de l'internationalisation… le tout dans un seul et même repository.

Un monorepo permet de centraliser non seulement tout le code et toutes les dépendances, il peut également simplifier les différents build.

Pourquoi utiliser un monorepo ?

Imaginez la gestion de la situation ci-dessus en polyrepo, c'est-à-dire avec un repository par projet : déjà avec le cas décrit, on aurait cinq repos d'applications et cinq repos de libraries ! Non seulement ça fait dix repos séparés à gérer, mais il faut aussi en gérer les dépendances : chaque repo doit maintenir les versions de ses propres dépendances et les libraries et applications doivent s'assurer de rester compatibles les uns avec les autres, sans même parler de devoir déployer les libraries à chaque modification puis de mettre à jour chaque application en conséquence…l'enfer ! Ajoutez à cela le fait que chaque repo aura son propre tooling selon l'équipe qui le gère (linter, test runner, process de build) et vous verrez rapidement les équipes dupliquer énormément de code, parce que ça reste plus simple que d'essayer d'en partager en cross-repo.

Regardons les avantages ensemble : 

• gestion centralisée des dépendances — tous les projets restent compatibles parce qu'ils partagent leurs dépendances

• processus partagés — les builds, lints, tests etc peuvent être partagés, les applications ayant obligatoirement accès aux versions les plus récentes des libraries (et souvent sans même avoir besoin de les build)

• créer un nouveau projet devient trivial — tout ce dont ce projet peut avoir besoin est directement accessible

• collaboration augmentée et encouragée — les monorepos retirent la majorité des obstacles au partage entre équipes, et les développeurs de chaque équipe sont d'autant plus capables de contribuer aux autres projets

• des build accélérés — les meilleurs monorepos proposent des caches de build distribués : si rien n'a changé depuis que quelqu'un quelque part (y compris les agents CI) a build un projet, et vous souhaitez faire de même, votre machine n'exécutera pas le build de nouveau — il récupèrera l'artefact déjà généré

Dans ce cours, je vous propose de découvrir deux façons de gérer un monorepo Angular : les workspace Angular et Nx.

Gérez les monorepo avec le workspace Angular

L'équipe Angular propose les workspace comme solution de monorepo très simple : ils permettent de gérer plusieurs applications et libraries Angular dans un seul repo en partageant les dépendances.

Lorsque vous démarrez un nouveau projet, pour l'inscrire dans un workspace multi-projet, il suffit d'ajouter un flag :

ng new my-workspace --no-create-application

Ensuite, depuis la racine de ce workspace, pour générer un projet de type application :

ng generate application my-app

Ou, inversement, pour créer une library :

ng generate library my-lib

Tous les projets, par défaut, se retrouvent dans un dossier  projects  à la racine du workspace. Ils sont tous gérés par le même fichier  angular.json  , celui qui se trouve également à la racine du workspace.

Pourquoi choisir les workspace Angular ?

• intégration parfaite d'Angular — étant une solution native, un workspace pourra toujours être à jour avec la dernière version d'Angular

• centralisation des solutions — les applications et les libraries gérées dans le même repo avec les mêmes dépendances

• courbe d'apprentissage — il n'y a pas grand chose de nouveau à apprendre pour adopter un workspace multi-projet

Quelles sont les limites ?

• pas de cache de build — il n'y a pas d'accélération des build dans les workspace Angular

• les libraries doivent être build pour être utilisées — l'obligation de build les libraries est une limitation qui devient de plus en plus contraignante avec le temps

• limité à Angular — on n'a pas la possibilité d'intégrer d'autres types de projet (libraries TS, applications frontend d'autres frameworks, applications backend…)

• lourd à l'échelle — lorsqu'on commence à multiplier les projets, la gestion d'un workspace devient de plus en plus lourde

Les workspace Angular représentent un excellent premier pas dans le monde des monorepos, et fournissent plusieurs avantages avec une courbe d'apprentissage très faible.

Gérez les monorepo avec Nx

Si les Angular workspace offrent une simplicité appréciable pour démarrer, Nx représente l'évolution naturelle quand votre monorepo grandit : plus de fonctionnalités, plus de possibilités, mais en échange d'une courbe d'apprentissage plus élevée. Toutes les features qui "manquent" au workspace sont présentes chez Nx.

Pour créer un monorepo Nx, la commande est la suivante :

npx create-nx-workspace@latest

Vous suivez ensuite un wizard qui vous permet de générer le monorepo avec les options que vous souhaitez.

Les étapes de cette génération montrent déjà quelques-unes des possibilités étendues de Nx. Une fois que vous avez choisi le dossier où le monorepo sera généré, vous avez la question suivante :

Les monorepos Nx permettent de faire cohabiter des projets construits avec différents frameworks et libraries !

Si vous choisissez Angular, le wizard vous donne la possibilité de générer un projet standalone plutôt qu'un monorepo si vous le souhaitez, ce qui permet de bénéficier du tooling Nx même dans un seul projet.

Un peu plus loin, le wizard montre une autre force de Nx : la possibilité de choisir des outils qui sont supérieurs à ceux fournis par défaut par Angular.

esbuild est le bundler par défaut d'Angular depuis la v17 et, en 2025, je vous conseille de le garder sauf si vous avez besoin de l'écosystème Webpack, notamment les plugins.

Jasmine a bien servi le monde Angular pendant des années, mais aujourd'hui, ce test runner est dépassé. Aujourd'hui, je dirais que Jest est le strict minimum : il est bien plus rapide, et il possède des outils qui manquent cruellement à Jasmine (notamment les parametrised tests). Vitest est plus rapide mais plus récent, donc l'adopter n'est pas totalement sans risque.

Nx propose d'ajouter un gestionnaire de tests end-to-end, là où Angular ne le fait plus par défaut depuis la version 12. Vous pouvez toujours commencer sans cette capacité et l'ajouter plus tard.

Nx termine par vous demander si vous voulez ajouter un workflow CI, et propose des configurations pour plusieurs plateformes.

Pourquoi choisir Nx ?

Il y a un nombre incalculable de features et de possibilités disponibles dans les monorepos Nx, donc ici je vais vous parler des fonctionnalités que je trouve les plus utiles :

• on n'a pas besoin de build les libraries pour s'en servir (dans la plupart des cas) — ça peut paraître anodin, mais non seulement ça réduit considérablement les temps de build, ça en réduit également la complexité : plus besoin de jongler les versions

• les commandes  affected  — Nx maintient automatiquement un graph de quels projets dépendent de quels autres projets : du coup, quand vous changez une library par exemple, Nx peut lint/test/build seulement les projets qui sont affectés, là où on aurait tendance à tout rebuild "au cas où" dans un workspace Angular

• gestion de projets non-Angular — vous pouvez maintenir toutes vos apps (frontend, backend, CLI…) dans votre monorepo, permettant une réelle intégration de tout votre écosystème ; il y a même des plugins pour intégrer Gradle, .Net, Go, Flutter…

• cache distribué — comme mentionné précédemment, si quelqu'un quelque part a build votre application et que rien n'a changé entre-temps, lorsque vous allez build l'application chez vous, ce sera instantané : Nx récupèrera le dernier build automatiquement (nécessite Nx Cloud ou la version self-hosted)

• gestion des frontières de module — on peut gérer quels projets ont le droit de dépendre de quels autres projets, s'assurant de ne plus jamais importer le mauvais modèle

En effet. Voici les inconvenants principaux : 

• courbe d'apprentissage — non seulement il y a de nouvelles commandes à connaître, c'est un tout autre modèle mental

• couplage à l'outil — on devient totalement dépendant de Nx pour tout : les workflow de build et de test, les plugins, les générateurs…

• délais de mise à jour — les plugins Nx, n'étant pas maintenus par l'équipe Angular, peuvent mettre un peu de temps avant d'être à jour avec les toutes dernières versions

• potentiels coûts Nx Cloud — si vous voulez maximiser les bénéfices d'utiliser Nx, soit il faut un abonnement Nx Cloud (dont le prix augmente avec le nombre de développeurs), soit il faut gérer leur proposition self-hosted (plus de travail de maintenance)

Et le verdict ?

Quand votre écosystème Angular commence à évoluer, les workspace Angular peuvent être largement suffisants. Cependant, lorsque les choses se complexifient, lorsque vous ajoutez d'autres types de projets, lorsque vous avez 5+ projets à gérer, le overhead ajouté par Nx commence à valoir le coup.

Comme toujours, il n'y a pas une seule bonne réponse : mon objectif ici est de vous proposer des outils pour votre réflexion.

À vous de jouer

Contexte

Vous architecturez une solution complète pour une nouvelle équipe :

• applications

  • une application Angular à destination de vos clients

  • une autre pour la gestion back-office

  • un dashboard en Vue pour la direction

  • une API NestJS ; 

• libraries

  • une library Angular pour les components UI

  • trois libraries TS pur (sans builder) pour les couches Clean Architecture — domain, application, infrastructure

Consigne

1. Générez un monorepo Nx avec la commande mentionnée dans ce chapitre, en créant la première application Angular

2. Ajoutez les plugins Vue et NestJS au monorepo

3. Générez les autres applications et les libraries comme décrit ci-dessus

Corrigé

Voici à quoi devraient ressembler vos commandes exécutées :

npx create-nx-workspace@latest
nx add @nx/vue
nx add @nx/nest

nx g @nx/angular:app apps/back-office
nx g @nx/vue:app apps/dashboard
nx g @nx/nest:app apps/api

nx g @nx/angular:lib libs/ui-components
nx g @nx/js:lib libs/domain
nx g @nx/js:lib libs/application
nx g @nx/js:lib libs/infrastructure

En résumé

• les monorepos centralisent plusieurs projets dans un seul repository, simplifiant la gestion des dépendances et du tooling, et favorisant la collaboration entre équipes

• les workspace Angular offrent une solution native et simple pour débuter avec les monorepos, parfaite pour les petits écosystèmes mais limitée en fonctionnalités avancées

• Nx apporte des capacités professionnelles comme le cache distribué, les commandes  affected  , et le support multi-framework, au prix d'une courbe d'apprentissage plus élevée

• le choix entre workspace et Nx dépend de votre échelle : les workspaces suffisent pour 2-4 projets simples, tandis que Nx devient rentable dès 5+ projets ou avec des besoins de performance

Que votre application vive en standalone, dans un workspace, ou dans un monorepo, il est temps de nous pencher sur la configuration : comment gérer les environnements, les variables, et les dépendances pour que chaque projet puisse s'adapter à différents contextes de déploiement ?