Monorepo avec Rust : organisation du code en pratique

Monorepo avec Rust : organisation du code en pratique

Un monorepo est une approche de gestion de code où plusieurs projets ou composants sont stockés dans un seul dépôt. Dans l'écosystème Rust, cette pratique est particulièrement populaire grâce au support intégré de Cargo Workspace. Dans cet article, nous allons voir comment organiser un monorepo avec Rust en pratique : de la création de la structure à la gestion des dépendances et aux tests. Vous apprendrez à éviter les erreurs courantes et à rendre votre base de code évolutive.

Qu'est-ce que Cargo Workspace et pourquoi en avez-vous besoin

Cargo Workspace est un mécanisme qui permet de gérer plusieurs crates (bibliothèques ou exécutables) au sein d'un même projet. Au lieu de créer des dépôts séparés pour chaque composant, vous les regroupez dans une structure unique. Cela offre plusieurs avantages :

• Système de construction unifié — une seule commande cargo build compile tous les crates.
• Dépendances partagées — les dépendances dupliquées sont résolues une seule fois, ce qui réduit la taille du binaire final.
• Tests simplifiés — vous pouvez exécuter les tests de tous les crates avec une seule commande.
• Cohérence des versions — tous les composants utilisent les mêmes versions de bibliothèques.

Le monorepo est particulièrement utile pour les microservices, les bibliothèques à usage général ou les projets avec une séparation claire en couches (par exemple, noyau, API, CLI).

Création de la structure du monorepo

Commençons par un exemple pratique. Supposons que nous développions un système de gestion de tâches. Nous aurons trois crates :

• core — une bibliothèque avec la logique métier.
• cli — un exécutable pour la ligne de commande.
• server — un serveur web (exécutable).

Créons d'abord le répertoire racine et le fichier Cargo.toml pour le workspace :

mkdir task_managercd task_manager# Création du Cargo.toml racinetouch Cargo.toml

Dans le Cargo.toml racine, nous spécifions le workspace :

[workspace]members = [    "core",    "cli",    "server",]

Créons maintenant chaque crate avec cargo new :

cargo new core --libcargo new clicargo new server

Après cela, la structure ressemblera à ceci :

task_manager/├── Cargo.toml          # Workspace racine├── core/│   ├── Cargo.toml│   └── src/│       └── lib.rs├── cli/│   ├── Cargo.toml│   └── src/│       └── main.rs└── server/    ├── Cargo.toml    └── src/        └── main.rs

Notez que le Cargo.toml racine ne contient pas de section [package], seulement [workspace]. Ceci est important pour un fonctionnement correct.

Gestion des dépendances entre les crates

L'une des tâches clés dans un monorepo est de configurer correctement les dépendances entre les crates. Dans notre exemple, cli et server dépendent de core. Spécifions cela dans leurs Cargo.toml :

Pour cli/Cargo.toml :

[package]name = "cli"version = "0.1.0"edition = "2021"

[dependencies]core = { path = "../core" }clap = { version = "4.0", features = ["derive"] }  # Dépendance externe pour CLI

Pour server/Cargo.toml :

[package]name = "server"version = "0.1.0"edition = "2021"

[dependencies]core = { path = "../core" }actix-web = "4"  # Dépendance externe pour le serveur web

Dans le Cargo.toml racine, vous pouvez également spécifier des dépendances communes si elles sont nécessaires à tous les crates, mais cela se fait généralement individuellement. Cependant, le workspace permet de résoudre les conflits de versions : si deux crates utilisent la même bibliothèque, Cargo récupérera automatiquement une seule version.