Flutter-Monorepo mit Melos

super-dev ✓

vor 8 Monaten • 6 min Lesezeit • 1,2k Aufrufe

■

Artikel 3 von 3 — Flutter in der Produktion

Offline-first, Riverpod, Melos-Monorepo: ernsthaftes Mobile, kein Prototyp.

Ein ernstzunehmendes Flutter-Produkt ist nie ein einzelnes Package: Da ist die mobile App, ein Design System, ein API-Client, vielleicht ein Feature-Modul pro Team. Sie in getrennten Repos zu halten, verwandelt jede übergreifende Änderung in einen Reigen aus pub publish und Versions-Bumps. Melos verwaltet dieses Dart/Flutter-Monorepo: ein Repo, mehrere Packages, Befehle, die überall auf einmal laufen.

In Packages aufteilen

Die Packages werden in einem Ordner (oft packages/ ) abgelegt und im Root deklariert. Jedes behält seine eigene pubspec.yaml ; die App referenziert die anderen als Pfadabhängigkeiten , und Melos verknüpft alles lokal:

Dart
 1// packages/feature_auth/lib/feature_auth.dart
 2import 'package:core_api/core_api.dart';
 3
 4class AuthRepository {
 5  AuthRepository(this._api);
 6  final ApiClient _api;
 7
 8  Future<Session> signIn(String email, String password) {
 9    return _api.post('/auth/login', {'email': email, 'password': password});
10  }
11}

Die Grenze zwischen Packages wird zur Architekturgrenze : feature_auth hängt von core_api ab, nie umgekehrt. Der Abhängigkeitsgraph ist explizit, überprüfbar und bricht die Kompilierung, sobald er verletzt wird.

Die melos.yaml-Datei

Der Kern der Konfiguration deklariert die Packages und wiederverwendbare Scripts , die über den gesamten Graphen ausgeführt werden:

YAML

1name: my_app

2packages:

3 - app

4 - packages/**

6scripts:

7 analyze:

8 run: melos exec -- dart analyze .

9 test:

10 run: melos exec --dir-exists=test -- flutter test

11 description: Lance les tests de chaque package qui en a.

melos exec führt einen Befehl in jedem Package aus; Filter wie --dir-exists=test oder --diff zielen auf eine Teilmenge ab — beispielsweise nur die seit dem Hauptbranch geänderten Packages , was die CI erheblich beschleunigt.

Bootstrap und Verknüpfung

melos bootstrap (oder melos bs ) ist der Schlüsselbefehl: Er installiert die Abhängigkeiten aller Packages und löst die Pfadabhängigkeiten zwischen ihnen auf. Kein manuelles flutter pub get Package für Package, keine desynchronisierten Versionen mehr. Man führt ihn nach jedem git clone und nach jeder Änderung an pubspec.yaml aus. Die Melos-Dokumentation beschreibt jeden Filter und jeden Hook.

Versionierung und CI

Melos setzt auf Conventional Commits : melos version liest die Historie, berechnet den Bump für jedes betroffene Package, aktualisiert die CHANGELOG.md und propagiert die neuen Versionen an abhängige Packages. Ein fix: in core_api erhöht core_api und alles, was davon abhängt, konsistent.

›melos bootstrap → installiert und verknüpft alles
›melos run analyze → statische Analyse überall
›melos run test → Tests über den gesamten Graphen
›melos version → Bumps + Changelogs aus den Commits

In der CI ist die typische Abfolge bootstrap , dann analyze , dann test — oft auf die geänderten Packages via --diff=origin/main beschränkt, um nicht bei jedem Push alles erneut durchzuführen.

Ein Monorepo ist nicht nur eine Ordnerstruktur: Es ist das Versprechen, dass eine übergreifende Änderung ein einziger Commit, ein einziger Build, ein einziges Review bleibt. Melos hält dieses Versprechen für Flutter.

• super-dev — portfolio.app

// Weiter in FLUTTER

■

Offline-First-Sync mit Flutter + Firebase

9 min • 2,2k Aufrufe

≋

Eine testbare Flutter-Architektur mit Riverpod

8 min • 2,0k Aufrufe

super-dev — full-stack

In Packages aufteilen

Die melos.yaml-Datei

Bootstrap und Verknüpfung

Versionierung und CI