Laravel 11 ve 12: Sadeleşen İskelet ve Geçiş Rehberi

Laravel 11 ve 12, çerçevenin "iskeleti sadeleştir, geliştiriciyi hızlandır" yönündeki evrimini sürdürüyor. Bu rehberde sürüm bazında hangi değişikliklerin günlük iş akışını etkilediğini, hangi varsayımların artık geçersiz olduğunu ve geçiş sırasında nelere dikkat etmeniz gerektiğini adım adım ele alıyoruz.

Kapsam ve Önkoşullar

• Hedef kitle: Laravel'in temel kavramlarına (routing, Eloquent, service container, Artisan) aşina orta seviye geliştiriciler.
• Sürüm kapsamı: Laravel 11 ve 12. Bu yazıda sürüm numarası, çıkış tarihi veya sürüme özel API imzası gibi doğrulanmamış ayrıntılar yer almaz; yalnızca çerçevenin bu sürüm ailesinde benimsediği ve dokümantasyonda belgelenen yapısal yaklaşımlar açıklanır.
• Önkoşul: Çalışan bir PHP ortamı ve Composer. Laravel 11 ile birlikte gelen minimum PHP sürümü, önceki ana sürümlere göre yükseltilmiştir; kurulum öncesi composer.json dosyanızdaki PHP kısıtını kontrol edin.
• Doğrulama notu: Aşağıdaki komut ve yapılandırma örnekleri, çerçevenin standart iskeletini varsayar. Kendi projenizde çalıştırmadan önce ilgili sürümün resmi dokümantasyonuyla karşılaştırın.

1. Sadeleşen Uygulama İskeleti

Laravel 11'in en görünür etkisi, yeni projelerde gelen dosya yapısının küçülmesidir. Önceki sürümlerde iskelette hazır gelen bazı yapılandırma dosyaları ve sağlayıcı sınıfları artık varsayılan olarak üretilmez; bunların yerini çerçevenin içindeki mantıklı varsayılanlar alır.

Bunun pratik anlamı şudur: Bir ayarı özelleştirmek istediğinizde dosyanın "zaten orada olmasını" beklemeyin. Gerekli yapılandırmayı php artisan komutlarıyla yayınlayarak (publish) oluşturursunuz.

# Yeni bir uygulama iskeleti oluşturma
composer create-project laravel/laravel example-app

# Belirli bir yapılandırma dosyasını iskelete dahil etme
php artisan config:publish

config:publish komutu, iskelette bulunmayan yapılandırma dosyalarını seçerek projenize eklemenizi sağlar. Yalnızca gerçekten değiştirmeniz gereken dosyaları yayınlayın; aksi halde çerçevenin varsayılanlarından gelen güncellemeleri elle takip etmek zorunda kalırsınız.

Yaygın hata

Eski bir projeden kopyaladığınız config/*.php dosyalarını yeni iskelete olduğu gibi taşımak. Bu dosyalar eski varsayılanları "dondurur" ve çerçevenin yeni davranışlarını sessizce devre dışı bırakabilir. Geçişte yapılandırmayı sıfırdan, yalnızca ihtiyaç duyduğunuz anahtarlarla kurun.

2. Uygulama Bootstrap'ı ve Yönlendirme

Laravel 11 ile birlikte uygulamanın başlatılması (bootstrap) ve ara katman (middleware) kaydı daha merkezi bir yapıya taşındı. Önceki sürümlerde app/Http/Kernel.php içinde tutulan HTTP çekirdek yapılandırması ve app/Console/Kernel.php içindeki konsol zamanlamaları, yeni iskelette farklı bir düzenlemeyle ele alınır.

Zamanlanmış görevleri tanımlarken artık ayrı bir Kernel sınıfına bağımlı değilsiniz; bunlar uygulamanın bootstrap dosyası üzerinden tanımlanır:

// routes/console.php içinde zamanlanmış görev tanımı
use Illuminate\Support\Facades\Schedule;

Schedule::command('emails:send')->daily();

Ara katmanları ise uygulama bootstrap dosyasında (bootstrap/app.php) yapılandırırsınız:

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->append(YourMiddleware::class);
})

Güvenlik etkisi

Ara katman kaydının merkezileşmesi, güvenlikle ilgili middleware'lerin (kimlik doğrulama, CSRF, rate limiting) nerede tanımlandığını tek bir noktaya toplar. Geçiş sırasında eski Kernel dosyanızdaki middleware sırasını dikkatle karşılaştırın; sıralama değişiklikleri isteklerin beklenmedik şekilde kimlik doğrulamadan geçmesine yol açabilir.

3. Veritabanı ve Migration Varsayılanları

Yeni iskelette migration dosyalarının bir kısmı sadeleştirilmiştir. Örneğin varsayılan kullanıcı tablosu migration'ı, önceki sürümlerde ayrı ayrı yer alan bazı tabloları tek dosyada toplayacak şekilde düzenlenmiştir.

Bu, mevcut projelerin migration geçmişini etkilemez; yalnızca yeni projelerin başlangıç noktasını değiştirir. Var olan bir veritabanınız varsa migration dosyalarını elle "birleştirmeye" çalışmayın — üretimde çalışmış migration'ları değiştirmek, migrations tablosundaki kayıtlarla tutarsızlık yaratır.

Yaygın hata

Çalışmış bir migration dosyasını düzenleyip yeniden çalıştırmayı beklemek. Laravel, daha önce çalıştırılmış migration'ları tekrar uygulamaz. Şema değişikliği için her zaman yeni bir migration oluşturun:

php artisan make:migration add_status_to_orders_table --table=orders

4. Sağlık Kontrolü Uç Noktası

Laravel 11 ile gelen yapısal yeniliklerden biri, uygulama sağlığını izlemek için kullanılan hazır bir uç noktadır. Dağıtık ortamlarda yük dengeleyici veya konteyner orkestrasyonu, uygulamanın ayakta olup olmadığını bu uç nokta üzerinden sorgulayabilir.

# Sağlık kontrolü uç noktasını etkinleştirme
php artisan install:api

install:api komutu, API ile ilgili iskelet parçalarını (örneğin routes/api.php ve gerekli bağımlılıkları) projenize ekler. Sağlık kontrolü uç noktasının yolunu ve davranışını, ilgili sürümün dokümantasyonundan doğrulayın; çünkü bu tür uç noktaların varsayılan yolu sürümler arasında değişebilir.

Güvenlik etkisi

Sağlık uç noktaları genellikle kimlik doğrulaması istemez. Bu uç noktaların yalnızca iç ağdan erişilebilir olmasını sağlayın; dışarıya açık bırakılan bir sağlık uç noktası, altyapı bilgisi sızdırabilir veya kötüye kullanılabilir.

5. Geliştirici Deneyimini Etkileyen Araçlar

Laravel 11 ve 12 hattında öne çıkan tema, tekrarlayan işleri azaltan yardımcı araçlardır. Bunları kullanırken sürüm farklarını göz önünde bulundurun:

• Artisan komutları: İskelet kurulumu ve yapılandırma yayınlama adımları php artisan üzerinden yürütülür. Kullanılabilir komut listesini php artisan list ile kontrol edin; sürüme göre komut kümesi değişir.
• Yerel geliştirme ortamı: Laravel ekosisteminde yerel geliştirmeyi kolaylaştıran araçlar (örneğin Sail veya php artisan serve) sürümden bağımsız olarak kullanılabilir. Hangi aracın hangi sürümde önerildiğini resmi dokümantasyondan teyit edin.
• Test altyapısı: Yeni iskelette test yapılandırması da sadeleştirilmiştir. Testleri çalıştırmadan önce phpunit.xml veya tercih ettiğiniz test çalıştırıcısının yapılandırmasının projenizde güncel olduğundan emin olun.

6. Geçiş Stratejisi

Mevcut bir Laravel projesini 11 veya 12'ye taşırken sıralı bir yaklaşım izleyin:

1. PHP sürümünü yükseltin. Çerçevenin gerektirdiği minimum PHP sürümünü composer.json ve resmi dokümantasyondan doğrulayın.
2. Bağımlılıkları güncelleyin. Üçüncü parti paketlerinizin yeni Laravel sürümünü desteklediğinden emin olun; desteklemeyen paketler geçişin en sık tıkanma noktasıdır.
3. Yapılandırmayı gözden geçirin. Eski Kernel dosyalarındaki middleware ve zamanlama tanımlarını yeni yapıya taşıyın.
4. Testleri çalıştırın. Geçiş sonrası tüm test paketini çalıştırın; özellikle kimlik doğrulama ve yetkilendirme testlerine öncelik verin.
5. Kademeli dağıtın. Üretime geçmeden önce hazırlık (staging) ortamında sağlık kontrolü ve hata izleme davranışını doğrulayın.

Yaygın hatalar

• Sürüm atlamak: Ara ana sürümleri atlayarak doğrudan en yeni sürüme geçmek, yükseltme kılavuzlarındaki adımları takip etmeyi zorlaştırır. Resmi yükseltme rehberini sırayla izleyin.
• Varsayılanları görmezden gelmek: Sadeleşen iskelet, çerçevenin sizin adınıza karar verdiği anlamına gelir. Bu kararları bilin; özelleştirme gerekiyorsa açıkça yapılandırın.
• Test kapsamını küçümsemek: Middleware ve bootstrap değişiklikleri, test edilmeyen uç noktalarda sessiz davranış farkları yaratabilir.

Sonuç

Laravel 11 ve 12'nin geliştirici deneyimine katkısı, daha az dosya ve daha merkezi yapılandırma üzerinden gelir. Bu sadeliğin bedeli, çerçevenin varsayılanlarını bilinçli takip etmektir. Geçişte PHP sürümü, üçüncü parti paket uyumluluğu ve middleware/zamanlama taşımaları en kritik adımlardır. Sürüme özel yol, komut ve imza ayrıntılarını her zaman ilgili sürümün resmi dokümantasyonundan doğrulayın; bu rehberdeki yapısal yaklaşımlar sürümler arasında görece sabit kalan ilkeleri özetler.