Monorepo avec Rust : organisation du code en pratique

Monorepo avec Rust : organisation du code en pratique

Lors du développement de grands projets en Rust, la question se pose tôt ou tard : comment organiser le code pour qu'il reste maintenable, réutilisable et facilement évolutif ? Une approche populaire est le monorepo. Dans cet article, nous allons voir ce qu'est un monorepo dans le contexte de Rust, comment le configurer avec Cargo Workspaces et quelles astuces pratiques permettent d'éviter le chaos dans la base de code.

Ce contenu sera utile aussi bien aux débutants qui commencent à travailler sur de grands projets qu'aux développeurs expérimentés cherchant des moyens efficaces d'organiser le code.

Qu'est-ce qu'un monorepo et pourquoi en a-t-on besoin en Rust ?

Un monorepo (monorepository) est une approche où tout le code d'un projet (ou de plusieurs projets liés) est stocké dans un seul dépôt. Contrairement aux multi-repos, où chaque service ou bibliothèque vit dans un dépôt Git séparé.

Pourquoi les développeurs Rust choisissent-ils souvent le monorepo ?

\n
• Version unique des dépendances. Vous évitez les conflits lorsque différentes crates nécessitent différentes versions de la même bibliothèque.
\n
• Refactorisation simplifiée. La modification d'une API dans une crate est immédiatement visible dans toutes les crates dépendantes — le compilateur Rust signalera tous les endroits à corriger.
\n
• Compilation partagée. Cargo peut optimiser la construction en réutilisant les artefacts déjà compilés.
\n
• Historique unique des modifications. Vous n'avez pas besoin de synchroniser les commits entre différents dépôts.
\n

L'outil principal pour organiser un monorepo en Rust est Cargo Workspaces. Voyons comment l'utiliser en pratique.

Configuration de Cargo Workspaces : exemple pas à pas

Supposons que nous créons une application composée de trois parties :

\n
• la bibliothèque core_lib — logique commune ;
\n
• la bibliothèque utils — utilitaires ;
\n
• le fichier exécutable app — le binaire principal.
\n

Créons la structure du monorepo :

my_monorepo/\n├── Cargo.toml          # manifeste racine du workspace\n├── core_lib/\n│   ├── Cargo.toml\n│   └── src/\n│       └── lib.rs\n├── utils/\n│   ├── Cargo.toml\n│   └── src/\n│       └── lib.rs\n└── app/\n    ├── Cargo.toml\n    └── src/\n        └── main.rs\n

Étape 1. Cargo.toml racine

[workspace]\nmembers = [\n    "core_lib",\n    "utils",\n    "app",\n]\n

Désormais, les trois crates font partie d'un même workspace. Cargo les gérera comme un tout.

Étape 2. Dépendances internes

Dans le fichier app/Cargo.toml, indiquons qu'il dépend de nos bibliothèques :

[package]\nname = "app"\nversion = "0.1.0"\nedition = "2021"\n\n[dependencies]\ncore_lib = { path = "../core_lib" }\nutils = { path = "../utils" }\n

Étape 3. Écriture du code

Exemple de code dans core_lib/src/lib.rs :

pub fn greet(name: &str) -> String {\n    format!("Hello, {}!", name)\n}\n

Dans app/src/main.rs, utilisons cette fonction :

use core_lib::greet;\n\nfn main() {\n    println!("{}", greet("Rust Developer"));\n}\n

Étape 4. Compilation et exécution

Les commandes cargo build, cargo test et cargo run fonctionnent pour tout le workspace. On peut aussi exécuter une crate spécifique :

cargo run -p app\ncargo test -p core_lib\n

Voici la configuration de base. Passons maintenant à des pratiques plus avancées.

Organisation avancée : modules, tests et versionnage

Lorsque le nombre de crates augmente, il est important de respecter une discipline. Voici quelques conseils