Monorepo avec Kotlin : organisation du code en pratique

Monorepo avec Kotlin : organisation du code en pratique

Dans le développement logiciel moderne, le choix entre monorepo et multirepo est de plus en plus fréquent. Pour les projets en Kotlin, en particulier ceux utilisant Kotlin Multiplatform ou une architecture microservices, le monorepo devient un outil puissant. Dans cet article, nous allons voir comment organiser correctement le code dans un monorepo en Kotlin, examiner des exemples pratiques et les meilleures pratiques pour vous aider à éviter les erreurs typiques.

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

Un monorepo est une approche où tout le code d'un projet (ou de plusieurs projets liés) est stocké dans un seul dépôt. Dans le contexte de Kotlin, cela peut inclure :

• Bibliothèques communes — utilitaires, modèles de données, DTO.
• Modules d'applications — backend (Ktor, Spring), frontend (Kotlin/JS), applications mobiles (Kotlin Multiplatform).
• Scripts et configurations — CI/CD, Dockerfile, scripts Gradle.

Les principaux avantages du monorepo pour les projets Kotlin :

• Version unique des dépendances — tous les modules utilisent la même version de Kotlin et des bibliothèques, réduisant ainsi le risque de conflits.
• Refactorisation simplifiée — une modification de l'API dans un module est immédiatement visible dans tous les modules dépendants.
• Configuration CI/CD plus facile — un seul pipeline pour tous les composants.
• Transparence — toute la base de code est accessible en un seul endroit.

Cependant, il y a aussi des inconvénients : la taille du dépôt peut augmenter et le temps de clonage peut s'allonger. Mais pour les projets Kotlin de taille moyenne à grande, le monorepo s'avère souvent être la solution optimale.

Structure du monorepo : modèle pratique

Une bonne organisation des dossiers est la clé du succès. Examinons une structure typique pour un projet Kotlin utilisant Gradle :

my-kotlin-monorepo/├── build.gradle.kts          # Script de construction racine├── settings.gradle.kts       # Configuration des modules├── gradle.properties         # Paramètres généraux Gradle├── gradle/│   └── libs.versions.toml    # Version Catalog (recommandé)├── modules/│   ├── common/               # Utilitaires et modèles communs│   │   ├── build.gradle.kts│   │   └── src/│   ├── backend/              # Service backend avec Ktor│   │   ├── build.gradle.kts│   │   └── src/│   ├── android-app/          # Application Android│   │   ├── build.gradle.kts│   │   └── src/│   └── web-client/           # Client Kotlin/JS│       ├── build.gradle.kts│       └── src/├── scripts/                  # Scripts auxiliaires│   └── deploy.sh└── docs/                     # Documentation    └── architecture.md

Le fichier settings.gradle.kts inclut les modules :

rootProject.name = "my-kotlin-monorepo"

include(":modules:common")include(":modules:backend")include(":modules:android-app")include(":modules:web-client")

Dans le fichier racine build.gradle.kts, vous pouvez définir des plugins et dépendances communs :

plugins {    kotlin("jvm") version "1.9.22" apply false    kotlin("multiplatform") version "1.9.22" apply false    id("com.android.application") version "8.2.0" apply false}

Gestion des dépendances : Version Catalog et Convention Plugins

Dans un monorepo, il est essentiel d'éviter la duplication des versions de dépendances. Pour cela, Kotlin utilise le Version Catalog (fichier libs.versions.toml).

Exemple de gradle/libs.versions.toml :

[versions]kotlin = "1.9.22"ktor = "2.3.7"coroutines = "1.8.0"

[libraries]kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }ktor-server-core = { module = "io.k