Bölüm 12 — Konu 59: Monorepo Mimarisi (Melos)

Bir önceki derste (Konu 58), kendi paketini/plugin'ini nasıl paketleyip yayınlayacağını öğrendik — hatta federated plugin mimarisinde birden fazla paketin (benim_pluginim, benim_pluginim_platform_interface, benim_pluginim_android...) bir arada geliştirildiğini gördük. Peki bu paketler ayrı ayrı Git repo'larında mı yaşamalı, yoksa tek bir repo'da bir arada mı? Bu ders, ikinci seçeneği — monorepo mimarisini — ve bunu yönetmenin standart Flutter aracı olan Melos'u işliyor.

#Monorepo Nedir? Neden İhtiyaç Duyulur?

Monorepo ("mono" + "repository"), birden fazla bağımsız paketin/uygulamanın, tek bir Git repo'sunda bir arada tutulmasıdır — karşıtı, her paketin kendi ayrı repo'sunda yaşadığı "polyrepo" yaklaşımıdır.

# Polyrepo (her paket ayrı repo):
github.com/sirket/benim_pluginim
github.com/sirket/benim_pluginim_platform_interface
github.com/sirket/benim_pluginim_android
github.com/sirket/benim_pluginim_ios

# Monorepo (tek repo, birden fazla paket):
github.com/sirket/benim_pluginim_monorepo/
├── packages/
│   ├── benim_pluginim/
│   ├── benim_pluginim_platform_interface/
│   ├── benim_pluginim_android/
│   └── benim_pluginim_ios/

Neden monorepo? Konu 58'deki federated mimariyi hatırla — dört ayrı paketi birlikte geliştiriyorsun. Polyrepo'da, platform_interface paketinde bir arayüz değişikliği yaptığında, bunu dört ayrı repo'da, dört ayrı git commit/git push ile senkronize etmen gerekir; bir PR, tek bir değişikliği gösteremez çünkü değişiklik birden fazla repo'ya yayılmıştır. Monorepo'da, tek bir commit, tüm paketlerdeki ilgili değişikliği birlikte taşır — bu, gerçek dünyadaki büyük Flutter projelerinde (hatta Flutter'ın kendi SDK'sı da kısmen bu mantıkla organize edilir) yaygın bir tercihtir.

Pratik senaryo — ne zaman işine yarar:

• Bir şirket, birden fazla uygulaması (müşteri app'i, kurye app'i, admin paneli) arasında ortak bir ui_kit paketi ve ortak bir api_client paketi paylaşıyorsa.
• Konu 58'deki gibi bir federated plugin geliştiriyorsan.
• Bölüm 7 Konu 34'te öğrendiğimiz Clean Architecture'ı paket seviyesinde uygulamak istiyorsan — örneğin domain, data, presentation katmanlarını her birini ayrı bir Dart paketi yaparak (bu, katmanlar arası bağımlılığı pubspec.yaml'daki dependencies ile derleme zamanında zorunlu kılar — bir presentation paketi, yanlışlıkla data paketinin iç detaylarına erişemez, çünkü onu hiç import etmemiştir).

#Melos Nedir?

Melos, monorepo'daki birden fazla Dart/Flutter paketini yönetmek için yazılmış bir komut satırı aracıdır — "birden fazla paket için flutter pub get'i tek seferde çalıştır", "değişen paketleri bul ve hepsini birden pub.dev'e yayınla" gibi işleri otomatikleştirir.

dart pub global activate melos

#melos.yaml — Monorepo'nun Tanımı

# melos.yaml (repo kök dizininde)
name: benim_pluginim_monorepo

packages:
  - packages/**   # bu desene uyan HER pubspec.yaml, Melos tarafından "paket" sayılır

scripts:
  analyze:
    run: melos exec -- flutter analyze     # Konu 46'daki flutter analyze'ı HER paket için çalıştırır
  test:
    run: melos exec -- flutter test        # Konu 45'teki testleri HER paket için çalıştırır

packages: - packages/** deseni, packages/ klasörü altındaki her pubspec.yaml içeren klasörü otomatik olarak bir workspace paketi sayar — yeni bir paket eklediğinde, melos.yaml'ı elle güncellemene gerek kalmaz.

#Temel Komutlar

melos bootstrap   # (kısaca: melos bs) — TÜM paketlerin bağımlılıklarını kurar ve
                   # birbirine bağımlı olanları YEREL sembolik link ile bağlar

melos exec -- flutter analyze   # verdiğin komutu HER paket içinde sırayla çalıştırır
melos run analyze               # melos.yaml'da tanımlı "analyze" script'ini çalıştırır

melos list       # workspace'teki tüm paketleri listeler
melos list --graph  # paketler arası bağımlılık grafiğini gösterir

melos bootstrap'ın kritik özelliği — yerel bağımlılık linki: Normalde, benim_pluginim paketi benim_pluginim_platform_interface'e bağımlıysa, pubspec.yaml'da şunu yazman gerekir:

dependencies:
  benim_pluginim_platform_interface: ^1.0.0   # pub.dev'den İNDİRİLMİŞ sürüm

Ama sen her ikisini de aynı anda geliştiriyorsan, platform_interface'te yaptığın bir değişikliğin, pub.dev'e yayınlamadan, hemen benim_pluginim'de görünmesini istersin. melos bootstrap, bunu otomatik olarak halleder — pubspec_overrides.yaml adlı bir dosya kendisi oluşturur ve paketi yerel klasördeki sürüme yönlendirir:

# melos'un OTOMATİK oluşturduğu pubspec_overrides.yaml (elle düzenlenmez, .gitignore'a eklenir)
dependency_overrides:
  benim_pluginim_platform_interface:
    path: ../benim_pluginim_platform_interface

Bu, Bölüm 7'de öğrendiğimiz Dependency Injection'a paralel bir fikir — geliştirme sırasında gerçek (pub.dev) bağımlılık yerine yerel (path-based) bir "sahte" bağımlılık enjekte ediyorsun, tıpkı testte gerçek bir Repository yerine FakeRepository enjekte etmen gibi.

#Sürüm Yönetimi ve Toplu Yayınlama

Konu 53'te öğrendiğimiz semantic versioning, monorepo'da karmaşıklaşır — dört paketten sadece biri değiştiyse, sadece onu mu yeni sürüme çıkarmalısın, yoksa hepsini birden mi? Melos, bunu iki stratejiyle çözer:

melos version   # DEĞİŞEN paketleri tespit eder, CHANGELOG.md'lerini
                # (Konu 58'i hatırla) OTOMATİK günceller, semantic versioning
                # kurallarına göre sürüm numaralarını artırır

melos publish --dry-run   # TÜM değişen paketleri, Konu 58'deki
                           # `flutter pub publish --dry-run` mantığıyla, TEK KOMUTLA dener
melos publish              # ve gerçekten yayınlar

melos version'ın en değerli özelliği: Conventional Commits formatında commit mesajları yazıyorsan (fix: ..., feat: ..., BREAKING CHANGE: ...), Melos hangi paketin hangi sürüm artışını (patch/minor/major — Konu 53) hak ettiğini otomatik hesaplar — bu, Konu 53'te elle karar verdiğimiz semantic versioning kararının, büyük ölçekte otomatikleştirilmiş halidir.

#CI/CD ile Entegrasyon

Bölüm 10 Konu 46'da öğrendiğimiz GitHub Actions pipeline'ını hatırla — monorepo'da bunun tek bir farkı var: hangi paketin değiştiğini tespit edip, sadece onun testlerini/analizini çalıştırmak (gereksiz yere tüm paketleri test etmemek için):

# .github/workflows/ci.yml
- name: Melos bootstrap
  run: |
    dart pub global activate melos
    melos bootstrap

- name: Analyze & Test (tüm paketler)
  run: |
    melos run analyze
    melos run test

Küçük monorepo'larda (birkaç paket) genelde tüm paketleri her seferinde test etmek yeterince hızlıdır; büyük monorepo'larda (düzinelerce paket) melos exec --diff gibi bayraklarla sadece değişen paketleri hedeflemek mümkündür — bu, Konu 46'daki CI hızını optimize etme disiplininin monorepo'ya özel bir uzantısıdır.

#Ne Zaman Monorepo, Ne Zaman Polyrepo?

Dürüst bir uyarı: Monorepo, her proje için gerekli değildir — tıpkı Konu 58'deki federated plugin mimarisinin "basit bir plugin için gereksiz" olması gibi:

• Tek bir uygulama geliştiriyorsan (bu tutorial boyunca yaptığımız gibi), monorepo'ya ihtiyacın yok — lib/ klasörü altında modüler klasörleme (Bölüm 7'de öğrendiğimiz katmanlama) yeterlidir.
• Birden fazla bağımsız paket/uygulama, aynı anda ve sıkça birbirine bağımlı olarak geliştiriliyorsa (bir şirketin birden fazla app'i + ortak kütüphaneleri, ya da Konu 58'deki gibi federated bir plugin ailesi), monorepo + Melos gerçek bir zaman kazancı sağlar.

#Gerçek Dünya Örneği — Flutter'ın Kendi Ekosistemi

Bilmekte fayda var: Google'ın kendi flutter/packages reposu (kamera, google_maps_flutter, url_launcher gibi resmi plugin'lerin kaynak kodu), tam olarak bu monorepo mantığıyla organize edilir — onlarca federated plugin, tek bir repo'da, benzer bir yapı ve otomasyon (Melos'a benzer kendi araçlarıyla) ile yönetilir. Bu dersteki mimari, "teorik bir öneri" değil, Flutter ekosisteminin kendisinin kullandığı bir desendir.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Monorepo, birden fazla bağımsız paketi tek bir Git repo'sunda bir arada tutar; polyrepo'nun tersine, paketler arası senkronize değişiklikleri tek commit'te yönetmeyi sağlar.
• Melos, monorepo'daki paketleri yönetmek için standart Flutter aracıdır — melos.yaml ile paketleri tanımlar, melos bootstrap/exec/run ile ortak komutları otomatikleştirir.
• melos bootstrap, birbirine bağımlı paketleri pubspec_overrides.yaml ile yerel path'e bağlar — pub.dev'e yayınlamadan eşzamanlı geliştirmeyi mümkün kılar (Dependency Injection'a paralel bir fikir).
• melos version/melos publish, Konu 53'teki semantic versioning ve Konu 58'deki pub publish işlemlerini birden fazla paket için toplu ve (Conventional Commits ile) otomatik hale getirir.
• Monorepo, tek bir uygulama için gereksizdir; birden fazla, sık birbirine bağımlı paket/uygulama (özellikle Konu 58'deki federated plugin senaryosu) için değerlidir — Flutter'ın kendi resmi plugin reposu da bu mimariyi kullanır.

#📝 Ödevler

• [ ] melos paketini kur, Konu 58'de oluşturduğun paket(ler)i packages/ altına taşıyarak basit bir monorepo iskeleti kur, melos.yaml yaz.
• [ ] melos bootstrap çalıştır, oluşan pubspec_overrides.yaml dosyasının içeriğini incele ve ne işe yaradığını kendi cümlelerinle açıkla.
• [ ] melos.yaml'a, Bölüm 10 Konu 45/46'daki test ve analiz komutlarını çalıştıran bir scripts bölümü ekle, melos run ile çalıştır.
• [ ] Kendi cümlelerinle, "pubspec_overrides.yaml'ın, Bölüm 7'de öğrendiğimiz Dependency Injection ile neden benzer bir fikri paylaştığını" açıkla.
• [ ] Flutter'ın resmi flutter/packages GitHub reposuna göz at, kaç plugin'in bu tek repo altında toplandığını gözlemle.

Sıradaki konu: Bölüm 12 — Konu 60: Erişilebilirlik (Accessibility) Derinlemesine