Nx n’est pas un outil JavaScript : c’est un orchestrateur de travail

Souvent perçu comme un outil JavaScript, Nx est avant tout un orchestrateur de tâches basé sur un graphe de dépendances. Cet article explique pourquoi Nx devient particulièrement pertinent dans les monorepos polyglottes (Go, TypeScript, Foundry, codegen, etc.)

I. Nx n’est pas un outil JavaScript : c’est un orchestrateur de travail  

Nx est souvent présenté — et perçu — comme un outil JavaScript.
Un “truc pour Angular”, ou au mieux “un runner pour monorepos Node”.

Cette perception est compréhensible…
mais fondamentalement incorrecte.

Nx n’est pas un outil JS.
Nx est un orchestrateur de travail.

Et c’est précisément pour cette raison qu’il apparaît presque naturellement dès qu’un dépôt devient polyglotte.

II. L’idée reçue : “Nx, c’est pour le frontend”  

Historiquement, Nx est né dans l’écosystème JavaScript/TypeScript.
Il propose des plugins riches pour :

• React
• Angular
• Node
• React Native
• tests, linting, bundlers…

Résultat :

• on associe Nx à un stack JS
• on pense qu’il est “hors sujet” pour Go, Solidity, ou du codegen

Cette conclusion est basée sur l’interface, pas sur le cœur du système.

III. Ce qu’est vraiment Nx  

Nx repose sur trois concepts fondamentaux :

1. Des tâches
2. Un graphe de dépendances
3. Un cache basé sur les inputs / outputs

Et aucun de ces concepts n’est lié à JavaScript.

Nx ne “build pas du JS”.
Nx exécute des commandes et raisonne sur leur impact.

IV. Nx raisonne en tâches, pas en langages  

Pour Nx, une tâche est simplement :

• une commande
• avec des entrées (fichiers, variables, versions)
• produisant des sorties (artefacts, dossiers, résultats)

Exemples parfaitement valides pour Nx :

• go test ./...
• go build ./cmd/api
• forge test
• forge build
• graphql-codegen
• pnpm build

Pour Nx, toutes ces tâches sont équivalentes.

Le langage n’a aucune importance.
Seule compte la relation entre entrées, travail et sorties.

V. Go, Foundry, codegen : Nx est dans son élément  

Prenons un dépôt réel :

• backend en Go
• smart contracts en Solidity (Foundry)
• frontend en TypeScript
• génération GraphQL partagée

Sans orchestrateur :

• scripts éparpillés
• CI pleine de conditions
• duplication local / CI
• rebuilds inutiles

Avec Nx :

• chaque activité devient une tâche explicite
• les dépendances sont déclarées
• le cache est automatique

Exemples de tâches Nx typiques :

• contracts:test → forge test
• contracts:build → forge build
• api:test → go test
• api:build → go build
• codegen → graphql-codegen
• web:build → pnpm build

Nx ne fait rien de “magique” ici.
Il structure le travail.

VI. Le graphe de tâches : la vraie source de vérité  

C’est ici que Nx devient réellement intéressant.

Dans un dépôt polyglotte, la question centrale n’est pas :

Comment exécuter une commande ?

Mais :

Quel travail est impacté par ce changement ?

Nx construit un graphe de dépendances entre projets et tâches :

• le frontend dépend du codegen
• le codegen dépend du schéma GraphQL
• l’API dépend des contrats
• etc.

Résultat :

• un changement dans le schéma GraphQL déclenche uniquement :
  • le codegen
  • puis les builds qui en dépendent
• le reste est ignoré (ou servi depuis le cache)

Ce graphe devient la vérité opérationnelle du dépôt.

Pas les scripts CI.
Pas les conventions implicites.
Le graphe.

VII. Pourquoi Nx apparaît naturellement dans un repo polyglotte  

Au début, on s’en passe.

Puis le dépôt grandit :

• un nouveau langage
• un nouveau type de build
• un nouveau générateur
• un nouveau pipeline CI

Et soudain :

• Docker cache ne suffit plus
• les scripts deviennent illisibles
• la CI devient lente et fragile
• local ≠ CI

À ce moment-là, une question émerge :

Comment savoir quoi reconstruire sans tout refaire ?

Nx répond précisément à cette question.

Pas parce qu’il est “puissant”,
mais parce qu’il est au bon niveau d’abstraction.

VIII. Nx vs scripts : une différence de nature  

Scripts shell / npm / Make :

• exécutent ce qu’on leur dit
• ne savent rien du contexte
• ne comprennent pas l’impact d’un changement

Nx :

• modélise le travail
• comprend les dépendances
• décide quoi exécuter et quoi ignorer

Ce n’est pas un meilleur script.
C’est une autre catégorie d’outil.

IX. Ce que Nx ne fait pas (et c’est important)  

Nx :

• ne gère pas ton environnement système
• ne remplace pas Docker
• ne remplace pas tes outils de build

Il orchestre.

Il décide quand exécuter une tâche,
pas comment cette tâche est implémentée.

C’est précisément ce qui le rend universel.

Conclusion  

Nx n’est pas un outil JavaScript.
Il est souvent utilisé dans l’écosystème JS, mais ce n’est pas sa nature.

Nx est un orchestrateur de travail :

• polyglotte par conception
• centré sur les tâches
• piloté par un graphe de dépendances
• optimisé pour éviter le travail inutile

Si ton dépôt commence à contenir :

• plusieurs langages
• plusieurs types de build
• plusieurs pipelines implicites

Alors Nx n’apparaît pas par mode.
Il apparaît par nécessité.

🔗 Liens utiles  

• Nx — Core Concepts: Tasks, Graph, and Caching