Monorepo

Monorepo, birbirinden farklı ama ilişkili birden fazla projenin — bir frontend uygulaması, bir backend API, paylaşılan bir bileşen kütüphanesi, dahili araçlar — her birinin ayrı bir repoya bölünmesi yerine ("polyrepo" veya "multirepo" stratejisi) tek bir Git deposunda bir arada tutulduğu bir kaynak kod kontrolü stratejisidir. Google, Meta ve Vercel gibi şirketler ünlü şekilde devasa monorepo'lar çalıştırır; SaaS/startup dünyasında yaygın bir desen, bir Next.js frontend'i, bir backend API'yi ve her ikisinin de kullandığı kodları (tipler, UI bileşenleri, yardımcı fonksiyonlar) içeren paylaşılan bir `packages/` dizinini içeren bir monorepo'dur. AI/SaaS geliştiricileri için neden önemli: bir monorepo, projeler arası değişiklikleri atomik hale getirir — paylaşılan bir API tipini değiştirirseniz, buna bağlı frontend ve backend'i aynı commit içinde güncellersiniz ve CI, ayrı repolarda ayrı PR'lar ve versiyon güncellemeleriyle bir değişikliği koordine etmek yerine tüm değişikliği birlikte doğrulayabilir. Ayrıca kod paylaşımını önemsiz hale getirir (iki uygulama arasında bir yardımcı fonksiyonu paylaşmak için özel bir paketi private bir registry'ye yayımlamaya gerek yoktur) ve tüm kod tabanı için tek bir doğruluk kaynağı sağlar; bu özellikle AI kodlama ajanları için kullanışlıdır — monorepo erişimi olan bir ajan, frontend ve backend repoları için ayrı bağlam ve ayrı oturumlara ihtiyaç duymadan, tam yığın bir değişikliğin her iki tarafını da tek bir geçişte görüp doğru şekilde güncelleyebilir. Ödünleşim ise araç karmaşıklığıdır: naif bir monorepo kurulumu, gerçekte ne değiştiğine bakmaksızın her değişiklik için tüm test paketini ve tüm build'i çalıştırır, bu da ölçek büyüdükçe yavaşlar, bu yüzden monorepo'lar genellikle özel build orkestrasyon araçlarına ihtiyaç duyar. Nasıl çalışır: Turborepo, Nx veya Bazel gibi monorepo araçları, düz bir çok paketli repo üzerine iki önemli yetenek ekler — bağımlılık grafiğinin farkında görev çalıştırma (yalnızca belirli bir değişiklikten gerçekten etkilenen paketleri, artı bunlara bağlı olan her şeyi yeniden derleyip test etme) ve uzak önbellekleme (başka bir geliştirici veya CI zaten bu tam commit'te belirli bir paketi derlediyse, işi yeniden yapmak yerine o build çıktısını yeniden kullanma). Uygulamalı örnek: bir ekibin monorepo'sunda `apps/web`, `apps/api`, `packages/ui` (paylaşılan React bileşenleri) ve `packages/types` (paylaşılan TypeScript tipleri) bulunuyor. Bir geliştirici, `packages/types` içindeki paylaşılan `Invoice` tipine yeni bir `taxAmount` alanı eklemek için değiştiriyor. `turbo run build` çalıştırmak bağımlılık grafiğini dolaşır, `packages/types`'ın değiştiğini görür ve yalnızca o paketi değil, onu import eden aşağı akıştaki her şeyi de otomatik olarak yeniden derler ve test eder — `apps/api` (artık `taxAmount`'ı doldurması gerekiyor) ve `apps/web` (bunu göstermesi gerekiyor) — hiçbir şekilde değişen tipe bağımlı olmayan `packages/ui`'yi atlayarak, her değişiklikte tüm repoyu yeniden derlemeye kıyasla önemli miktarda CI süresi tasarrufu sağlar.