Monorepo Flutter con Melos

super-dev ✓

hace 8 meses • 6 min de lectura • 1,2k lecturas

■

Offline-first, Riverpod, monorepo Melos: mobile en serio, no un prototipo.

Un producto Flutter serio nunca es un solo package: está la app móvil, un design system, un cliente API, quizá un módulo de funcionalidad por equipo. Mantenerlos en repos separados convierte cada cambio transversal en un vals de pub publish y de bumps de versión. Melos gestiona este monorepo Dart/Flutter: un repo, varios packages, comandos que se ejecutan por todas partes de una sola vez.

Dividir en packages

Los packages se organizan bajo una carpeta (habitualmente packages/ ) y se declaran en la raíz. Cada uno conserva su propio pubspec.yaml ; la app referencia los demás como dependencias de ruta , y Melos los enlaza todos localmente:

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}

El límite entre packages se convierte en una frontera de arquitectura : feature_auth depende de core_api , nunca al revés. El grafo de dependencias es explícito, verificable, y rompe la compilación en cuanto se infringe.

El archivo melos.yaml

El núcleo de la configuración declara los packages y los scripts reutilizables, ejecutados sobre el conjunto del grafo:

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 lanza un comando en cada package; los filtros como --dir-exists=test o --diff apuntan a un subconjunto — por ejemplo únicamente los packages modificados desde la rama principal, lo que acelera considerablemente la CI.

Bootstrap y enlace

melos bootstrap (o melos bs ) es el comando clave: instala las dependencias de todos los packages y resuelve las dependencias de ruta entre ellos. Sin más flutter pub get manuales package por package, sin versiones desincronizadas. Se ejecuta después de cada git clone y tras cualquier cambio en pubspec.yaml . La documentación de Melos describe cada filtro y cada hook.

Versionado y CI

Melos se apoya en los commits convencionales : melos version lee el historial, calcula el bump de cada package afectado, actualiza los CHANGELOG.md y propaga las nuevas versiones a los packages dependientes. Un fix: en core_api incrementa core_api y todo lo que depende de él, de forma coherente.

›melos bootstrap → instala y enlaza el conjunto
›melos run analyze → análisis estático en todos
›melos run test → tests sobre todo el grafo
›melos version → bumps + changelogs desde los commits

En CI, la secuencia típica es bootstrap , luego analyze , luego test — habitualmente restringida a los packages modificados mediante --diff=origin/main para no reejecutar todo en cada push.

Un monorepo no es solo una organización de carpetas: es la promesa de que un cambio transversal sigue siendo un único commit, un único build, una única revisión . Melos hace que esa promesa se cumpla para Flutter.

• super-dev — portfolio.app

// Continuar en FLUTTER

■

Sync offline-first en Flutter + Firebase

9 min • 2,2k lecturas

≋

Una arquitectura Flutter testable con Riverpod

8 min • 2,0k lecturas

super-dev — full-stack

Dividir en packages

El archivo melos.yaml

Bootstrap y enlace

Versionado y CI