Composer Kurulumu ve PHP Bağımlılık Yönetimi

Yazar:komut.io ekibi PHP Sürüm Yönetimi ve Yapılandırma
0 Yorum

PHP projelerinde bağımlılık yönetimi, eskiden gerçek bir kabustu. Her kütüphaneyi manuel indirip, sürüm uyumlarını elle takip edip, “bu kütüphane şu versiyonun üzerinde çalışmıyor” hatalarıyla boğuşmak artık geride kaldı. Composer, PHP ekosistemindeki bu karmaşayı ortadan kaldıran ve modern PHP geliştirmenin vazgeçilmezi haline gelen bir araç. Bugün Composer’ı sıfırdan kurmanın, yapılandırmanın ve günlük sysadmin hayatında verimli kullanmanın pratik yollarını ele alacağız.

Composer Nedir ve Neden Önemlidir

Composer, PHP için yazılmış bir bağımlılık yöneticisidir. Pip’in Python için, npm’in Node.js için ne anlam ifade ettiğini biliyorsanız, Composer da PHP dünyasında tam olarak aynı rolü üstleniyor. Projenizin hangi kütüphanelere ihtiyaç duyduğunu bir composer.json dosyasında tanımlıyorsunuz, Composer da bunları Packagist deposundan (veya özel repolardan) çekip projenize kuruyor.

Sürüm çakışmaları, bağımlılık zinciri yönetimi, otomatik yükleme (autoloading) gibi konularda Composer hayat kurtarıyor. Özellikle birden fazla sunucuya deployment yapıyorsanız veya ekip olarak çalışıyorsanız, Composer olmadan iş yapmak artık düşünülemez bile.

Sistem Gereksinimleri

Composer’ı kurmadan önce birkaç şeyin hazır olması gerekiyor.

  • PHP 7.2.5 veya üzeri: Composer 2.x için bu minimum gereksinim. Eski sunucularda Composer 1.x kullanmak zorunda kalabilirsiniz ama kesinlikle tavsiye etmiyorum.
  • php-cli: Komut satırından PHP çalıştırmak için gerekli.
  • php-json: JSON işlemleri için.
  • php-mbstring: Çok baytlı string desteği.
  • php-zip: Paket indirme işlemleri için.
  • php-openssl: HTTPS bağlantıları için.
  • curl veya allow_url_fopen: Paketleri indirmek için bunlardan birinin aktif olması gerekiyor.

Sistemdeki PHP kurulumunu ve aktif uzantıları kontrol edelim:

php -v
php -m | grep -E "json|mbstring|zip|openssl|curl"

Linux Üzerinde Composer Kurulumu

Ubuntu/Debian Sistemlerde

Önce gerekli PHP paketlerini kuralım:

sudo apt update
sudo apt install php-cli php-json php-mbstring php-zip php-curl unzip -y

Şimdi Composer’ı resmi yöntemle indirelim. Composer’ı doğrudan curl veya php ile indirip doğrulama yaparak kurabiliyoruz:

cd /tmp
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === file_get_contents('https://composer.github.io/installer.sig')) { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

Bu adımların ardından çalışma dizininde composer.phar dosyası oluşuyor. Bunu sistem genelinde kullanılabilir hale getirelim:

sudo mv composer.phar /usr/local/bin/composer
sudo chmod +x /usr/local/bin/composer

Kurulumu doğrulayalım:

composer --version
# Composer version 2.x.x

CentOS/RHEL/AlmaLinux Sistemlerde

sudo dnf install php-cli php-json php-mbstring php-zip php-curl unzip -y

# Composer kurulum adımları aynı şekilde devam eder
cd /tmp
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php --install-dir=/usr/local/bin --filename=composer

--install-dir ve --filename parametrelerini kullanarak taşıma adımını atlayabilirsiniz. Tek komutla hem indirip hem de doğru yere kurmuş olursunuz.

Windows Üzerinde Composer Kurulumu

Windows tarafında Composer kurulumu oldukça basit. Resmi siteden Composer-Setup.exe indirip çalıştırabilirsiniz. Kurulum sırasında PHP’nin yolunu belirtmenizi isteyecek, genellikle XAMPP veya WAMP kullanılıyorsa otomatik algılanıyor.

Eğer PowerShell veya WSL2 üzerinde çalışmayı tercih ediyorsanız, WSL2’de Linux adımlarını birebir uygulayabilirsiniz. Geliştirme ortamı olarak WSL2 kullanmak, Windows’ta PHP geliştirme yapanlar için gerçekten tavsiye ettiğim bir yaklaşım.

composer.json Dosyasını Anlamak

Composer’ın kalbi composer.json dosyasıdır. Yeni bir projeye başlarken şu komutla interaktif olarak bu dosyayı oluşturabilirsiniz:

mkdir myproject && cd myproject
composer init

Komut size projenin adı, açıklaması, lisansı ve bağımlılıklar hakkında sorular soracak. Sonuçta şuna benzer bir dosya oluşacak:

{
    "name": "company/myproject",
    "description": "Proje açıklaması",
    "type": "project",
    "require": {
        "php": ">=8.1",
        "monolog/monolog": "^3.0",
        "guzzlehttp/guzzle": "^7.5"
    },
    "require-dev": {
        "phpunit/phpunit": "^10.0",
        "squizlabs/php_codesniffer": "^3.7"
    },
    "autoload": {
        "psr-4": {
            "App\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\": "tests/"
        }
    }
}

Buradaki kritik ayrım: require production ortamında çalışması gereken paketler, require-dev ise sadece geliştirme ve test süreçlerinde kullanılan paketler. Sunucuya deployment yaparken --no-dev flag’ini kullanarak dev bağımlılıklarını yüklememek hem performans hem de güvenlik açısından önemli.

Temel Composer Komutları

Paket Kurma ve Güncelleme

# Tüm bağımlılıkları kur
composer install

# Yeni paket ekle
composer require guzzlehttp/guzzle

# Belirli bir versiyonla paket ekle
composer require symfony/console:^6.0

# Dev bağımlılığı ekle
composer require --dev phpunit/phpunit

# Paketleri güncelle
composer update

# Sadece belirli bir paketi güncelle
composer update monolog/monolog

# Paketi kaldır
composer remove guzzlehttp/guzzle

composer.lock Dosyasının Önemi

composer install komutunu çalıştırdığınızda eğer composer.lock dosyası mevcutsa, Composer bu dosyadaki tam sürümleri kullanır. Bu sayede ekipteki herkes ve sunucu, aynı paket versiyonlarıyla çalışır.

composer.lock dosyasını mutlaka Git’e commit etmelisiniz. Bu dosya olmadan farklı ortamlarda farklı davranışlar görmeniz kaçınılmaz olur.

composer update ise composer.json dosyasındaki version constraint’lere göre paketleri günceller ve composer.lock dosyasını yeniden oluşturur. Bu komutu production’da rastgele kullanmaktan kaçının.

Sürüm Kısıtlamalarını Doğru Kullanmak

Composer’da sürüm belirtme sözdizimini iyi anlamak kritik. Yanlış constraint tanımlamak güvenlik açıklarına veya kırık güncellemelere yol açabilir.

  • ^2.0: 2.0 veya üzeri, ancak 3.0’ın altında (major version değişmez). Semantic versioning’e uyumlu projeler için önerilen.
  • ~2.3: 2.3 veya üzeri, ancak 3.0’ın altında. Küçük farklar var ama ^’ya benzer.
  • 2.3.*: 2.3.x serisinin herhangi bir patch versiyonu.
  • >=2.0 <3.0: Explicit aralık tanımı.
  • 2.3.1: Tam olarak bu versiyon. Kilitli kalmak istiyorsanız, ama genellikle tavsiye edilmez.
  • dev-main: Git dalından direkt yükleme. Production’da kullanmayın.

Gerçek Dünya Senaryosu: Laravel Projesi Kurulumu

Diyelim ki bir müşteri için Laravel tabanlı bir proje teslim aldınız ve staging sunucusuna kuracaksınız. İşte tipik bir süreç:

# Projeyi git'ten çek
git clone https://github.com/company/project.git /var/www/project
cd /var/www/project

# Production bağımlılıklarını kur, dev paketleri atlıyor
composer install --no-dev --optimize-autoloader --no-interaction

# Autoloader'ı optimize et (bu adım önemli)
composer dump-autoload --optimize

# Ortam dosyasını ayarla
cp .env.example .env
php artisan key:generate

Burada --optimize-autoloader flag’i, class map’i önceden oluşturarak autoloading performansını ciddi ölçüde artırıyor. Production sunucularda bunu atlamamak gerekiyor.

Autoloading Yapılandırması

Composer’ın en güçlü özelliklerinden biri PSR-4 standardına uygun otomatik yükleme sistemi. Kendi yazdığınız sınıfların otomatik yüklenmesi için composer.json dosyasına şunu ekliyorsunuz:

{
    "autoload": {
        "psr-4": {
            "App\": "src/",
            "Config\": "config/"
        },
        "files": [
            "src/helpers.php"
        ],
        "classmap": [
            "database/migrations"
        ]
    }
}

composer.json dosyasını değiştirdikten sonra autoloader’ı yeniden oluşturmanız gerekiyor:

composer dump-autoload
# Production için optimize edilmiş versiyon:
composer dump-autoload --optimize

Projenizde require '/path/to/autoload.php' satırını eklemek de unutulmamalı:

<?php
require __DIR__ . '/vendor/autoload.php';

use MonologLogger;
use MonologHandlerStreamHandler;

$log = new Logger('app');
$log->pushHandler(new StreamHandler('/var/log/myapp.log', Logger::WARNING));
$log->warning('Bu bir uyarı mesajıdır');

Özel (Private) Paket Depoları

Kurumsal ortamlarda herkese açık olmayan iç kütüphaneleriniz olabilir. Bunun için birkaç seçenek mevcut:

Satis ile özel Packagist mirror kurmak en yaygın kurumsal çözüm. Ancak basit senaryolar için composer.json içine direkt repo eklemek de işe yarıyor:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/company/private-library"
        },
        {
            "type": "path",
            "url": "../local-package"
        }
    ],
    "require": {
        "company/private-library": "^1.0"
    }
}

GitHub’daki private repolara erişim için authentication token gerekiyor. Bunu auth.json dosyasına veya Composer’ın global config’ine ekleyebilirsiniz:

composer config --global github-oauth.github.com YOUR_TOKEN_HERE

CI/CD Pipeline’larında Composer

Bir DevOps sysadmin olarak en çok vakit geçirilen konulardan biri Composer’ı CI/CD süreçlerine entegre etmek. Örnek bir GitHub Actions workflow:

- name: Install Composer dependencies
  run: |
    composer install 
      --no-interaction 
      --no-progress 
      --prefer-dist 
      --optimize-autoloader 
      --no-dev

Buradaki flag açıklamaları:

  • –no-interaction: Hiçbir şekilde kullanıcıdan girdi isteme. CI ortamlarında şart.
  • –no-progress: Progress bar gösterme, log dosyalarını temiz tutar.
  • –prefer-dist: Kaynak kod yerine hazır arşiv indir, daha hızlı.
  • –optimize-autoloader: Class map oluştur, performans için.
  • –no-dev: Dev bağımlılıklarını atlıyor.

Ayrıca CI süreçlerinde vendor klasörünü cache’lemek build sürelerini dramatik şekilde düşürüyor. Hangi CI aracını kullanırsanız kullanın, vendor dizinini composer.lock dosyasına göre cache’leyin.

Composer Cache Yönetimi

Composer, indirdiği paketleri lokal cache’de tutuyor. Bu bazen sorunlara yol açabilir veya disk alanı tüketebilir.

# Cache durumunu gör
composer config --list | grep cache

# Cache'i temizle
composer clear-cache
# veya
composer cache-clear

# Cache dizinini bul
composer config --global cache-dir

Linux’ta Composer cache genellikle ~/.composer/cache veya ~/.cache/composer altında bulunuyor. Docker container’larında veya geçici build ortamlarında cache’i devre dışı bırakmak mantıklı olabilir:

composer install --no-cache

Güvenlik Taraması

Composer, kullandığınız paketlerdeki bilinen güvenlik açıklarını kontrol edebilir. Composer 2.4 ve sonrasında bu özellik built-in olarak geliyor:

composer audit

Bu komut, composer.lock dosyasındaki paketleri Packagist’in güvenlik advisory veritabanıyla karşılaştırıyor. CI pipeline’larına bu adımı eklemek, güvenlik açıklı paketlerin production’a geçmesini engelliyor.

Eski versiyonlarda aynı iş için security-checker paketi kullanılıyordu ama artık composer audit yeterli.

Performans İpuçları

Büyük projelerde Composer kurulum sürelerini kısaltmak için birkaç pratik öneri:

Paralel indirme: Composer 2.x varsayılan olarak paralel indirme yapıyor, Composer 1.x’teyseniz prestissimo eklentisini kullanabilirsiniz ama asıl çözüm yükseltmek.

Mirror kullanmak: Özellikle Packagist’e erişimin yavaş olduğu ortamlarda (bazı kurumsal ağlar, belirli ülkeler) mirror tanımlamak hızı artırıyor:

composer config --global repo.packagist composer https://packagist.mirrors.example.com

--prefer-dist flag’i: Source kod yerine hazır zip/tar arşivlerini indiriyor, özellikle git history’ye ihtiyaç duymayan production ortamlarında çok daha hızlı.

Sorun Giderme

Composer ile çalışırken sık karşılaşılan sorunlar ve çözümleri:

Bellek hatası: PHP memory limit düşük olduğunda Composer çöküyor.

php -d memory_limit=-1 /usr/local/bin/composer install

SSL sertifika hatası: Kurumsal ağlarda özel CA sertifikaları soruna yol açabilir.

composer config --global cafile /path/to/ca-bundle.crt

Timeout sorunları: Yavaş bağlantılarda paket indirme timeout’a düşebilir.

composer config --global process-timeout 600

Platform requirement uyumsuzluğu: Lokal PHP versiyonu ile sunucu versiyonu farklıysa paket kurulumunda sorun çıkabilir. composer.json‘a platform config ekleyebilirsiniz:

{
    "config": {
        "platform": {
            "php": "8.1.0"
        }
    }
}

Bu sayede lokal makinenizde farklı bir PHP versiyonu olsa bile, sanki belirttiğiniz versiyonmuş gibi bağımlılık çözümlemesi yapılıyor.

Sonuç

Composer, modern PHP geliştirmenin temel taşlarından biri. Kurulumu basit, ama derinlemesine anlamak ve doğru kullanmak için biraz zaman yatırımı gerekiyor. composer.lock dosyasını commit etmek, production’da --no-dev kullanmak, autoloader’ı optimize etmek ve düzenli olarak composer audit çalıştırmak, öğrendiğiniz ilk günden itibaren alışkanlık haline getirmeniz gereken pratikler.

Sysadmin perspektifinden bakıldığında, Composer’ı CI/CD pipeline’larına doğru entegre etmek ve deployment süreçlerini standartlaştırmak, ekip içi tutarsızlıkları ve “bende çalışıyordu” sendromunun önüne geçiyor. Özellikle çok geliştiricili projelerde composer.lock disiplini, production’da yaşanan sürpriz bağımlılık problemlerini neredeyse sıfıra indiriyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir