5 Repo, 1 Kabus ve Kurtuluş Hikayesi

Bundan 6 ay önce, yönettiğim projede durum şuydu:

Web App: React projesi.
Mobile App: React Native projesi.
Admin Panel: Yine React.
Backend: Node.js API.
Shared UI: Ortak bileşen kütüphanesi (npm paketi).

Shared UI kütüphanesinde bir butonu güncellediğimizde, onu npm'e publish etmemiz, sonra diğer 3 projede npm update yapmamız gerekiyordu. Bazen versiyonlar uyumsuz oluyor, build patlıyordu. Kod paylaşımı tam bir kopyala-yapıştır cehennemine dönmüştü.

Ekiple oturduk ve radikal bir karar aldık: Monorepo.

Bu yazıda, Monorepo'nun sihirli dünyasını ve bu geçişi hangi araçlarla (Nx vs Turborepo) yapabileceğinizi anlatacağım.

Bölüm 1: Neden Monorepo?

Monorepo "bütün kodu tek bir klasöre yığmak" değildir. Monorepo, ilişkili projeleri tek bir çatı altında, akıllı bir build sistemiyle yönetmektir.

Atomic Commits: API'de bir alanı değiştirdiniz mi? Aynı commit içinde Frontend'i de güncelleyebilirsiniz. "API deploy oldu ama Frontend güncellenmedi" hatası tarih olur.
Code Sharing: Bir DateFormatter fonksiyonunu veya UserCard bileşenini paylaşmak için npm paketi yapmanıza gerek yok. Sadece import { UserCard } from '@myorg/shared-ui' dersiniz. Bitti.
Standartizasyon: Tüm projeler aynı ESLint, aynı Prettier, aynı TypeScript config'i kullanır.

Bölüm 2: Araçlar Savaşı (Nx vs Turborepo)

Piyasada iki büyük oyuncu var. İkisini de kullandım, işte dürüst karşılaştırmam:

Bizim projemizde Nx seçtik çünkü dependency graph (bağımlılık haritası) özellikleri çok güçlüydü.

Bölüm 3: "Affected" Komutlarının Gücü

Monorepo'nun en büyük korkusu şudur: "Tek bir dosyayı değiştirince tüm projeleri baştan mı build edeceğiz?"

Hayır. Akıllı build sistemleri (Nx/Turbo) sadece etkilenen projeleri bulur. Diyelim ki Shared UI kütüphanesini değiştirdiniz. Nx şuna bakar:

Web App bu kütüphaneyi kullanıyor mu? Evet. -> Build et.
Backend kullanıyor mu? Hayır. -> Dokunma.

Bu sayede CI/CD süreniz, projeniz büyüse bile sabit kalır (hatta düşer).

Bölüm 4: Cache Mekanizması

Nx veya Turborepo, build aldığınızda o build'in "parmak izini" (hash) alır ve cache'ler. Siz veya ekip arkadaşınız aynı kodu tekrar build etmeye çalıştığında, saniyeler süren işlem milisaniyeler içinde biter. Çünkü sonuç cache'ten gelir.

Uzaktan Cache (Remote Cache) kullandığınızda, CI/CD sunucunuz da bu cache'ten faydalanır. Bir developer'ın local'de yaptığı build'i, CI sunucusu tekrar yapmaz.

Bölüm 5: Gerçek Göç (Migration) Hikayesi

Polyrepo'dan Monorepo'ya geçiş 2 haftamızı aldı.

Workspace Kurulumu: Boş bir Nx workspace oluşturduk.
Taşıma: 5 ayrı repoyu apps/ klasörünün altına taşıdık. Git history'lerini korumak için biraz git subtree jimnastiği yaptık.
Refactor: Ortak kodları libs/shared klasörüne çıkardık ve import yollarını düzelttik.
Pipeline: GitHub Actions dosyamızı güncelledik. Artık her proje için ayrı pipeline yok, tek bir nx affected:build komutu var.

Sonuç:

Kod tekrarı %40 azaldı.
"Hangi versiyonu kullanıyorduk?" sorusu bitti.
Full-stack development (bir feature'ı baştan sona tek kişinin yapması) inanılmaz hızlandı.

Sonuç: Korkmayın, Birleşin

Ekibiniz 2-3 kişiden fazlaysa ve birden çok projeniz varsa, Monorepo lüks değil ihtiyaçtır. Başlangıçta konfigürasyon (tsconfig paths, eslint vb.) biraz uğraştırabilir ama uzun vadede kazandırdığı zaman ve huzur paha biçilemez.

Checklist:

[ ] Nx veya Turborepo'yu kurdum.
[ ] Ortak kodları libs/ altına taşıdım.
[ ] CI/CD pipeline'ımı "affected" komutlarına göre güncelledim.
[ ] Remote Cache'i aktif ettim.

Eğer mevcut spagetti yapınızı modern bir Monorepo'ya dönüştürmek istiyor ama nereden başlayacağınızı bilemiyorsanız, migration sürecini birlikte planlayabiliriz.

Monorepo'ya Geçiş: Nx ve Turborepo ile Kaostan Düzene