Melos ile Flutter Monorepo: Çok Paketli Proje Yönetimi

Bir Flutter uygulamasıyla başlarsın, sonra bir web paneli, bir de paylaşılan tasarım sistemi eklenir — ve bir gün üç ayrı repo'da aynı Dio sürümünü senkron tutmaya çalıştığını fark edersin. Flutter monorepo Melos kullanımı tam olarak bu noktada devreye giriyor: birden fazla Dart/Flutter paketini tek bir repo'da, tek bir bağımlılık çözümlemesiyle yönetmeni sağlıyor. Bu yazıda Melos'u sıfırdan kurup gerçek bir çok-paketli projeye nasıl oturtacağını, hangi script'leri tanımlaman gerektiğini ve nerede tökezleyebileceğini adım adım göreceksin.

💡 Pro Tip: Melos'a geçmeden önce mevcut projende kaç ayrı pubspec.yaml olduğunu ve bunların kaç tanesinin gerçekten "iç bağımlılık" ilişkisi kurduğunu say — cevap "bir elin parmaklarını geçmiyor" ise muhtemelen henüz monorepo'ya değil, sadece paylaşılan bir pakete ihtiyacın var.

İçindekiler

• Ne Zaman Monorepo'ya Geçilir (ve Ne Zaman Geçilmez)
• Tipik monorepo adayları
• Melos Kurulumu ve Konfigürasyon Anatomisi
• Paket Sınırlarını Çizmek: Feature, Core, Design System
• Bağımlılık Hizalama ve Sürüm Çakışmaları
• Script'ler: Bootstrap, Analyze, Test, Format
• Conventional Commits ile Otomatik Versiyonlama ve Changelog
• CI'da Sadece Değişen Paketi Test Etmek
• Pub Workspaces ile İlişkisi
• Geçiş Maliyeti ve Geri Dönüş
• SSS
• Flutter'da monorepo nasıl kurulur?
• Melos ne işe yarar?
• Aynı repoda birden fazla Flutter uygulaması nasıl yönetilir?
• Pub workspaces ile Melos arasındaki fark nedir?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Ne Zaman Monorepo'ya Geçilir (ve Ne Zaman Geçilmez)

Dart'ın resmi pub workspaces dokümantasyonu, ayrı repo'larda tutulan çoklu paketlerin somut maliyetini net biçimde tarif eder: her paket için tek tek dart pub get çalıştırman gerekir, paketler arası bağımlılık sürümleri zamanla birbirinden sapar ve editörün (IDE) her paket için ayrı bir analiz bağlamı oluşturması bellek kullanımını artırır. Bunlar teorik değil, ölçülebilir sürtünme noktaları — ve bir monorepo'ya geçmenin asıl gerekçesi de tam olarak bu üçü ortadan kaldırmak.

Peki ne zaman geçilmez? Bu sorunun resmi bir cevabı yok; burada kendi tecrübeme dayanıyorum. Eğer paketlerin birbirinden tamamen bağımsız yayınlanıyorsa, farklı ekipler tarafından farklı hızlarda geliştiriliyorsa ve aralarında gerçek bir kod paylaşımı yoksa, monorepo sana ek bir CI karmaşıklığı katmaktan başka bir şey vermez. Ben genelde şu basit testi uygularım: iki paket aynı hafta içinde birbirini etkileyen bir değişiklik görüyorsa, aynı repoda olmalılar; görmüyorsa ayrı kalsınlar.

Bir diğer pratik sinyal: paketlerin sürüm numaraları birbirinden bağımsız ilerlemesi gerekiyorsa (örneğin bir SDK paketinin dışarıya açık, sıkı bir semver taahhüdü varken, iç uygulamanın sürüm numarasının hiçbir anlamı yoksa) tek bir workspace içinde bunları zorlamak, Conventional Commits'in otomatik ürettiği versiyon artışlarını da karmaşıklaştırır. Böyle bir durumda önce paketleri ayrı repo'larda tutup, yalnızca gerçekten birlikte değişen bir alt küme oluştuğunda o alt kümeyi bir workspace'e taşımak daha sağlıklı bir yol.

Tipik monorepo adayları

• Mobil uygulama + backend SDK paketi: SDK'daki bir model değişikliği anında uygulamada derleme hatası vermeli, ayrı repo'da bu geri bildirim günler sonra gelir.
• Ana uygulama + design system paketi: Aynı anda geliştiriliyorlarsa tek pub get ile senkron kalmaları gerekir.
• Birden fazla Flutter uygulaması + paylaşılan çekirdek katman: flutter-clean-architecture yazısında anlattığım katmanlı mimariyi tek bir uygulama içinde uyguluyorsan monorepo gerekmez; aynı katmanları birden fazla uygulama arasında paylaşacaksan Melos devreye girer.

Melos Kurulumu ve Konfigürasyon Anatomisi

Melos, kendini bir "monorepo yönetim aracı" olarak tanımlıyor: birden fazla paket içeren Dart ve Flutter repo'larını yönetmek için, Conventional Commits üzerinden otomatik versiyonlamayı da destekleyen bir araç. Kurulumu tek satır:

1# Melos'u global pub paketi olarak etkinleştir
2dart pub global activate melos

Melos, kendi başına bir bağımlılık çözümleme motoru değil — Dart'ın kendi pub workspaces mekanizmasının üzerine inşa edilir. Ekip ve CI'ın aynı Melos sürümünü kullanması için dart pub add melos --dev ile paketi kök pubspec.yaml'a da bağımlılık olarak eklemen önerilir; bu durumda global etkinleştirme yerine pubspec'teki sürüm kullanılır. Bu yüzden ilk kurulum adımı, kök pubspec.yaml dosyanda bir workspace: listesi tanımlamaktır:

1name: my_project
2environment:
3  sdk: ^3.9.0
4publish_to: none
5workspace:
6  - packages/helper
7  - packages/client_package
8  - packages/server_package

Her alt paketin kendi pubspec.yaml'ına da tek bir alan eklenir; bu alan paketi workspace'e "kaydeder":

1name: client_package
2resolution: workspace
3environment:
4  sdk: ^3.9.0

Dikkat: bu, ayrı bir melos.yaml dosyası değil — Melos'un script ve versiyonlama ayarları da doğrudan kök pubspec.yaml içindeki bir melos: anahtarının altında yaşıyor. Yani tek dosya, tek kaynak: workspace listesi de, Melos'a özel komutlar da aynı pubspec.yaml'da.

Paket yollarını tek tek yazmak büyük repo'larda yorucu olabilir; Dart 3.11.0'dan (11 Şubat 2026) itibaren workspace tanımı glob pattern'leri destekliyor, yani packages/* gibi bir ifadeyle klasördeki tüm paketleri otomatik dahil edebilirsin — Mart 2026 itibarıyla bu özellik stabildi.

Workspace'e kaydettiğin bir paketi kullanmak, normal bir pub bağımlılığı eklemekten farklı görünmüyor — client_package'ın pubspec.yaml'ına helper: ^2.3.0 yazman yeterli (yerel helper sürümünün de bu kısıtı sağlaması gerekir), ayrıca bir path: bağımlılığı tanımlamana gerek yok:

1// client_package/lib/main.dart
2import 'package:helper/helper.dart';
3 
4void main() {
5  final result = HelperUtils.formatCurrency(1990);
6  print(result);
7}

Bootstrap çalıştırıldığında bu import, workspace içindeki helper paketinin yerel kaynak koduna çözümlenir — helper'da yaptığın bir değişiklik, pub get veya yayınlama beklemeden anında client_package tarafında görünür olur. Bu, monorepo'nun asıl pratik faydasının somutlaştığı yerdir: paylaşılan kod, gerçek zamanlı bir bağımlılık gibi davranır.

Kurulumdan sonra ilk komutun bootstrap olmalı:

1melos bootstrap

Bu komut üç şeyi birden yapar: her paketin bağımlılıklarını kurar (içeride pub get çalıştırarak), paketler arasında paylaşılan bağımlılıkları senkronize eder ve tanımlıysa bootstrap lifecycle script'lerini tetikler.

Paket Sınırlarını Çizmek: Feature, Core, Design System

Melos'un resmi dokümantasyonu tavsiye ettiği dizin yapısı konusunda son derece sade: kök dizinde apps/ (uygulamalarını barındıran klasör) ve packages/ (paylaşılan paketlerin durduğu klasör) ayrımı.

1my_project
2├── apps
3│   ├── apps_1
4│   └── apps_2
5├── packages
6│   ├── package_1
7│   └── package_2

Bunun ötesindeki "feature paketi / core paketi / design-system paketi" ayrımı resmi bir Melos veya Flutter kuralı değil — bu benim kendi projelerimde kullandığım bir ayrım. Ben genelde üç kategoriye ayırmayı tercih ederim:

• core: Ağ katmanı, model sınıfları, ortak yardımcı fonksiyonlar — hiçbir UI kodu barındırmaz.
• design-system: Tema, renk token'ları, paylaşılan widget'lar — bir önceki adımda bahsettiğim apps_1/apps_2 gibi tüm uygulamaların ortak görsel dili.
• feature: Belirli bir iş akışını (giriş, ödeme, profil) uçtan uca kapsayan, hem UI hem mantık içeren paket.

Bu üçlü ayrımın tek avantajı bağımlılık yönünü netleştirmesi: feature paketleri core ve design-system'e bağımlı olabilir, ama core asla bir feature paketine bağımlı olmamalı. Bunu zorunlu kılan bir Melos özelliği yok; disiplin, kod incelemesiyle (code review) korunur.

Bağımlılık Hizalama ve Sürüm Çakışmaları

Pub workspaces'in tanımı gereği tüm paketler tek bir paylaşımlı bağımlılık çözümlemesi kullanır — ve Dart aynı paketin birden fazla sürümünün aynı anda çözümlenmesine izin vermez. Bu, workspace'e geçtiğin an tüm paketlerinin aynı http veya dio sürümünde buluşmak zorunda kalacağı anlamına gelir; artık paket A'nın 5.x, paket B'nin 4.x kullandığı bir durum mümkün değil.

Bunun bir de faydalı tarafı var: workspace içindeki paketler birbirine bağımlıysa, kaynağı ne olursa olsun (pub.dev, git, path) otomatik olarak workspace içindeki yerel sürüme çözümlenir. Yani client_package, helper paketine ^2.3.0 diye pub.dev üzerinden bağımlıysa bile, aynı workspace'teysen gerçek pub.dev sürümü değil, yanı başındaki yerel kod çalışır — bu, bir değişikliği anında tüm bağımlı paketlere yansıtmanın (yayınlamaya gerek kalmadan) temel mekanizmasıdır.

Pratikte çakışma çözümü şöyle işler:

Pratikte bu tabloyu yönetmenin en kolay yolu, sık kullanılan üçüncü parti bağımlılıkların (http client, state management, test yardımcıları gibi) sürüm kısıtlarını tek bir yerde toplamak. Bazı ekipler bunu kök seviyede bir "ortak bağımlılıklar" paketi oluşturarak yapıyor: her feature paketi bu ortak paketi bağımlılık olarak alıyor, gerçek sürüm numaraları yalnızca o tek pakette tanımlı oluyor. Bu, Melos'un veya Dart'ın zorunlu kıldığı bir desen değil, ama sürüm çakışmalarını azaltan pratik bir alışkanlık.

Script'ler: Bootstrap, Analyze, Test, Format

Kendi komutlarını tanımlamak istediğinde, kök pubspec.yaml'daki melos: anahtarının altına bir scripts: bloğu eklersin. Resmi dokümantasyondaki somut örnek, build_runner'a bağımlı paketlerde kod üretimi tetikleyen bir generate script'idir:

1melos:
2  scripts:
3    generate:
4      run: melos exec -c 1 --depends-on build_runner -- dart run build_runner build

Bu script'i çalıştırmak için:

1melos generate

Resmi örnekte yalnızca generate somut olarak gösteriliyor; analyze, test ve format gibi script'ler doküman tarafından hazır sunulmuyor — aynı scripts: yapısıyla kendin tanımlaman gereken script'ler. Aynı desenle üç örnek daha yazabilirsin:

1melos:
2  scripts:
3    analyze:
4      run: melos exec -- dart analyze
5    test:
6      run: melos exec -- dart test
7    format:
8      run: melos exec -- dart format --set-exit-if-changed .

Her biri melos analyze, melos test, melos format olarak tetiklenir. melos exec, tanımlı script'i workspace'teki her paketin kendi dizininde çalıştıran çekirdek mekanizmadır; varsayılan olarak en fazla 5 paket eşzamanlı çalışır, -c 1 ile bunu sıraya alabilirsin.

Conventional Commits ile Otomatik Versiyonlama ve Changelog

Melos'un kendi tanımının ikinci cümlesi tam olarak buna işaret eder: Conventional Commits üzerinden otomatik versiyonlamayı destekler. Yani commit mesajlarını feat:, fix:, chore: gibi standart öneklerle yazdığında, Melos bu geçmişi okuyup her paket için hangi sürüm artışının (patch/minor/major) yapılması gerektiğini kendisi çıkarabilir ve değişiklik günlüğünü (changelog) buna göre üretebilir.

Bunun asıl değeri monorepo'da ortaya çıkar: tek bir commit birden fazla paketi etkileyebilir, ve her paketin kendi sürüm numarasını elle takip etmek hızla sürdürülemez hale gelir. Conventional Commits + Melos kombinasyonu bu takibi otomatikleştirir — commit mesajı disiplinin karşılığını burada alırsın.

CI'da Sadece Değişen Paketi Test Etmek

Monorepo büyüdükçe en büyük CI maliyeti, her push'ta workspace'teki tüm paketlerin testlerini baştan çalıştırmaktır — repo büyüdükçe bu israf da büyür. Buradaki hedef net: bir commit sadece packages/design_system'i değiştirdiyse, CI'ın packages/payments'ın testlerini de baştan çalıştırmasına gerek yok.

Bunu çözmenin doğrudan yolu Melos'un kendi --diff bayrağıdır: bir commit'e veya bir commit aralığına göre hangi paketlerin değiştiğini filtreler, sonra script'i yalnızca o paketlerde çalıştırır.

1melos exec --diff=origin/main...HEAD -- dart test

--diff=<commit hash> tek bir commit'e göre karşılaştırma yapar, --diff=<start>...<end> ise iki commit arasındaki aralığa göre filtreler. Elle yazacağın bir git diff ile değişen dizinleri tespit edip bunu kendi script'ine geçirmek de mümkün — ama bu, --diff bayrağının yerine değil, ona ek/tamamlayıcı bir yaklaşım olarak düşünülmeli (örneğin Melos'un filtre söz dizimine girmeyen özel bir eşleme mantığın varsa).

Bunu somutlaştırmak için basit bir zihinsel model kullanabilirsin: pipeline önce git diff --name-only origin/main...HEAD ile değişen dosya yollarını çıkarır, sonra bu yolları paket köklerine (packages/<ad>/) eşler, en sonunda yalnızca eşleşen paketlerin test script'ini tetikler. Değişen dosya bir core paketindeyse ve ona bağımlı feature paketlerin de testlerini çalıştırmak istiyorsan, Melos bu genişletmeyi zaten yerleşik olarak sağlıyor: --include-dependents bayrağı filtrelenmiş paket listesini, o paketlere bağımlı olan (transitive dependents) paketlere kadar genişletir — tersi yönde, bir paketin kendi bağımlılıklarını (transitive dependencies) da dahil etmek istersen --include-dependencies bayrağını kullanırsın.

1melos exec --diff=origin/main...HEAD --include-dependents -- dart test

flutter-ci-cd-github-actions-fastlane yazısında anlattığım GitHub Actions pipeline'ına bu filtrelemeyi ekstra bir adım olarak ekleyebilirsin.

Pub Workspaces ile İlişkisi

Buraya kadarki her adımda gördüğün gibi Melos, sıfırdan bir bağımlılık çözümleme sistemi icat etmiyor — Dart'ın kendi resmi pub workspaces özelliğinin üzerine bir orkestrasyon katmanı ekliyor. Pub workspaces'in kendisi Dart 3.6.0 ile (11 Aralık 2024) geldi ve o zamandan beri her workspace paketinin environment.sdk kısıtının en az ^3.6.0 olması gerekiyor. Melos, "Pub Workspaces" rehberine doğrudan yönlendirerek kurulumun ilk adımını buna dayandırır.

Bu ayrım pratikte önemli, çünkü bazı ekipler "zaten pub workspaces var, Melos'a ne gerek var" diye sorabiliyor. Cevap: eğer tek ihtiyacın paylaşımlı bağımlılık çözümlemesiyse, gerçekten Melos'suz da idare edebilirsin — workspace: listesini ve resolution: workspace alanlarını elle yönetip dart pub get'i kök dizinden çalıştırman yeterli olur. Melos'un devreye girdiği nokta, birden fazla paket için tekrarlayan komutları (test, format, analiz) tek seferde çalıştırmak ve sürüm/changelog yönetimini otomatikleştirmek istediğin an.

Peki Melos, çıplak pub workspaces'e göre ne katıyor? Aradaki farkı şöyle özetleyebilirim:

Yani workspace listesini glob ile tanımlamak (packages/*) tamamen Dart'ın kendi özelliği — Melos bunu miras alır, yeniden icat etmez. Melos'un asıl katkısı, bu paylaşılan çözümlemenin üzerine bir komut ve versiyonlama katmanı kurmasıdır.

Geçiş Maliyeti ve Geri Dönüş

Mevcut, ayrı repo'larda duran paketleri tek bir workspace'e taşırken karşılaşacağın en somut sürtünme noktası "stray files" (başıboş dosyalar) meselesi: kök ile her workspace paketi arasındaki dizinlerde kalan eski pubspec.lock ve .dart_tool/package_config.json dosyaları, workspace'e geçtikten sonra artık geçerli değildir ve pub get bunları siler. Pratikte bu, geçiş sonrası ilk melos bootstrap çalıştırmasının bu dosyaları silip yeniden üreteceği anlamına gelir (bunlar derleme önbelleği değil, bağımlılık çözümleme artefaktlarıdır) — sürpriz olmasın diye geçiş gecesi bunu planlı bir bakım penceresinde yapmanı öneririm.

Geri dönüş (workspace'i bozup paketleri tekrar ayrı repo'lara ayırma) konusunda resmi bir kılavuz yok; bu tamamen tersine mühendislik gerektiren manuel bir iştir — her paketin resolution: workspace alanını kaldırıp kendi bağımsız pubspec.lock'unu yeniden üretmen gerekir. Bu yüzden geçiş kararını, "birkaç hafta deneyip geri dönerim" diye değil, kalıcı bir mimari karar olarak almanı tavsiye ederim.

Geçişin insan tarafını da hafife alma: ekibin bir kısmı ayrı repo'lara alışkınsa, ilk haftalarda "neden benim değişikliğim başka paketin testini kırdı" gibi şaşkınlıklar yaşanabilir — bu aslında tek çözümlemenin beklenen, hatta istenen bir sonucu. Geçiş sonrası ilk sprint'te kısa bir iç eğitim (bootstrap ne zaman çalıştırılır, script'ler nasıl tetiklenir, sürüm artışı nasıl işler) uzun vadede çok daha az soru işareti bırakır.

SSS

Flutter'da monorepo nasıl kurulur?

Kök dizinde bir pubspec.yaml oluşturup içine workspace: altında alt paket yollarını listelersin, her alt paketin kendi pubspec.yaml'ına resolution: workspace eklersin ve ardından melos bootstrap çalıştırırsın. Bu üç adım, saf Dart pub workspaces mekanizmasının temelidir; Melos bunun üzerine script ve versiyonlama katmanı ekler.

Melos ne işe yarar?

Melos, birden fazla paket içeren Dart/Flutter repo'larını yönetmek için tasarlanmış bir araçtır: paketler arasında komut çalıştırmayı (melos exec), ortak script tanımlamayı (artık ayrı bir dosya yerine kök pubspec.yaml'daki melos: anahtarı altında) ve Conventional Commits üzerinden otomatik versiyonlama/changelog üretimini destekler.

Aynı repoda birden fazla Flutter uygulaması nasıl yönetilir?

Melos'un tavsiye ettiği dizin yapısı apps/ klasörü altında her uygulamayı ayrı bir alt dizin, packages/ klasörü altında paylaşılan paketleri ayrı alt dizinler olarak tutmaktır. Her uygulama kendi pubspec.yaml'ında packages/ altındaki paylaşılan paketlere path bağımlılığı yerine workspace çözümlemesiyle erişir; bootstrap komutu tüm uygulamaları ve paketleri tek seferde senkron tutar.

Pub workspaces ile Melos arasındaki fark nedir?

Pub workspaces, Dart SDK'sının kendi yerleşik özelliğidir (Dart 3.6.0'dan beri) ve yalnızca paylaşılan bağımlılık çözümlemesini sağlar. Melos bu temelin üzerine ek bir orkestrasyon katmanı kurar: paketler arası komut çalıştırma, bootstrap lifecycle script'leri ve Conventional Commits tabanlı otomatik versiyonlama — bunların hiçbiri çıplak pub workspaces'te yoktur.

Güncelleme (Eylül 2026)

Bu yazı 17 Mart 2026'da, Melos 7.4.1 ve Flutter 3.41.4 güncelken kaleme alındı. O tarihten bu yana ekosistemde birkaç somut değişiklik oldu:

• Flutter 3.47 (12 Ağustos 2026): 3.47'de Material/Cupertino kütüphaneleri çekirdek SDK'da durmaya devam ediyor; yanı sıra material_ui ve cupertino_ui, pub.dev'de bağımsız 1.0 paketleri olarak (opt-in) yayınlandı, çekirdekteki kopyaların resmi deprecation'ı ise Kasım sürümüne planlandı (detaylar için flutter-3-47-material-cupertino-paket-gecisi yazısına bakabilirsin). Bir Melos/pub-workspaces monorepo'sunda tüm paketler tek bir kök pubspec.lock paylaştığından, farklı uygulamaların bu paketlere farklı sürüm kısıtları koyması artık ayrı bir hizalama kararı gerektirebilir — bu, doğrulanmış bir vaka değil; tek paylaşımlı çözümlemeden çıkan beklenen bir sonuç. Kök pubspec.yaml'da tek bir sürüm aralığı sabitlemek makul bir önlem.
• Dart 3.11 (11 Şubat 2026) ve Dart 3.12 (Mayıs 2026): Glob tabanlı workspace üye keşfi (packages/*) geldi; Dart 3.12 sürüm notlarında ayrıca pub workspaces'in iç içe (nested) kullanılabildiği belgelendi — bu yeni bir özellik değil, nesting örneği hâlâ yalnızca ^3.6.0 sürüm kısıtı istiyor. Nesting, Mart 2026'da henüz dart.dev'de belgelenmemişti; Dart 3.12 ile belgelendi.
• Melos changelog'u ilerledi: Eylül 2026 itibarıyla pub.dev'deki güncel sürüm 8.9.0 (21 Eylül 2026); 7.4.1'den bu yana yalnızca bir ana sürüm (7'den 8'e) atlandı. 8.7.0 ile changed komutu, 8.9.0 ile de cherry-pick komutu ve --post-filter seçeneği eklendi.

Sonuç

Melos, Dart'ın pub workspaces özelliğinin üzerine kurulu ince ama etkili bir orkestrasyon katmanı: tek bir pubspec.yaml, tek bir bağımlılık çözümlemesi ve melos exec ile paketler arası komut çalıştırma. Kurulum üç adımdan ibaret — workspace listesi, resolution: workspace, melos bootstrap — ama gerçek değer script'leri (analyze, test, format) tanımladığında ve Conventional Commits ile versiyonlamayı otomatikleştirdiğinde ortaya çıkıyor.

Katmanlı mimariyi tek bir uygulama içinde nasıl kuracağını flutter-clean-architecture yazısında bulabilirsin; bu iki yaklaşımı birlikte kullanmak, her paketin kendi içinde temiz, paketler arasında da hizalı bir mimari kurmanı sağlar. CI pipeline'ına bu paketleri nasıl entegre edeceğini flutter-ci-cd-github-actions-fastlane yazısında bulursun. Native iOS tarafında aynı çok-modüllü mantığın karşılığını görmek istersen modular-architecture-spm ve spm-advanced-modular yazılarına bakabilirsin — araçlar farklı ama sorun aynı: paylaşılan kodu tek bir yerden, tutarlı bir sürümleme disipliniyle yönetmek. State management katmanını paketlere ayırırken flutter-state-management-riverpod yazısındaki desenler de doğrudan işine yarayacak.

Kaynaklar

• Melos — Getting Started — kurulum, workspace tanımı, bootstrap ve script anatomisinin resmi kaynağı.
• Melos paketi (pub.dev) — resmi paket tanımı ve sürüm geçmişi.
• Melos Changelog — sürüm bazlı değişiklik kayıtları.
• Dart — Pub Workspaces — pub workspaces mekanizmasının resmi dokümantasyonu, tek-repo-çoklu-paket dezavantajları ve minimum SDK kısıtı.
• Dart SDK Changelog — Dart 3.6.0 ve 3.11.0 sürüm tarihlerinin birincil kaynağı.
• Flutter — What's new in Flutter 3.47 — opt-in standalone material_ui/cupertino_ui 1.0 paketlerinin duyurusu (Güncelleme bölümü kaynağı).
• Flutter release notları — 3.47 genel sürüm notları (material_ui ayrışmasını içermez).