Belajar PHP - Composer & Autoloading

#Pendahuluan

Di episode 8 kita menyentuh autoloading PSR-4 lewat composer.json. Sekarang kita memakai Composer sebagai manajer dependensi yang sesungguhnya — alat yang mengubah PHP dari bahasa dengan ekosistem semrawut menjadi bahasa dengan pengelolaan paket profesional. Laravel, Symfony, PHPUnit, dan puluhan ribu package lain hidup di dalamnya.

Mengapa Composer penting? Karena aplikasi produksi tidak pernah ditulis 100% dari nol. Kalian akan menambah library, meng-upgrade versi, dan memastikan build di mesin developer, CI, dan server memakai dependensi yang identik. Satu composer.lock yang dipahami dengan benar bisa mencegah kelas masalah "works on my machine" yang paling menyakitkan.

#`composer init`: Memulai Proyek

composer init memandu pembuatan composer.json interaktif. Untuk kecepatan, langsung saja buat minimal:

composer init interaktif

cd ~/php-lab
composer init

Atau buat composer.json langsung:

composer.json

{
  "name": "devvnull/php-lab",
  "description": "Proyek praktik Belajar PHP",
  "type": "project",
  "license": "MIT",
  "require": {
    "php": "^8.5"
  },
  "autoload": {
    "psr-4": {
      "App\\": "src/"
    }
  },
  "scripts": {
    "test": "phpunit"
  }
}

Buat struktur awal dan file autoload:

Struktur awal + autoload

mkdir -p src public
composer dump-autoload

#`composer require` vs `composer install`

Dua perintah yang wajib dibedakan:

Perintah	Fungsi	Dipakai kapan
`composer require pkg/pkg`	Tambah dependensi ke `composer.json` + install	Menambah package baru
`composer install`	Install persis sesuai `composer.lock`	Reproduksi build (CI, server, tim)
`composer update`	Perbarui versi sesuai batasan `composer.json`	Upgrade dependensi

Menambah dan menginstall dependensi

composer require symfony/http-client
composer require --dev phpunit/phpunit
composer install

--dev menandai dependensi development (testing, static analysis) yang tidak perlu di produksi — dikontrol lewat composer install --no-dev saat deploy.

Tip

Alur tim yang sehat: composer.json menetapkan range versi yang diizinkan, composer.lock mengunci versi persis, dan composer install dipakai di semua environment. Commit composer.lock — ini asuransi build yang reproducible.

#`composer.json` vs `composer.lock`

Perbedaan keduanya adalah kunci disiplin dependensi:

composer.json — deklarasi range versi (misal "^8.5" berarti 8.5.x, dan untuk package "^5.0" berarti 5.x di atas 5.0). Ditulis tangan / oleh composer require.
composer.lock — daftar versi persis semua package + checksum, dihasilkan otomatis. Menjamin setiap instalasi identik.

Karena itu di CI/deployment, selalu jalankan composer install --no-dev --prefer-dist --no-progress — bukan composer update — agar hasil build tidak berubah diam-diam.

#PSR-4 Autoloading: Cara Kerja Persis

Dari konfigurasi episode 8, peta PSR-4 "App\\": "src/" berarti:

Pemetaan PSR-4

App\Payment\Gateway     →  src/Payment/Gateway.php
App\Service\OrderService →  src/Service/OrderService.php

Setiap namespace App\ diarahkan ke folder src/, dan setiap segment setelahnya adalah subfolder; nama class = nama file + .php. Setelah menambah file baru, composer dump-autoload memperbarui peta (atau aktifkan "optimize" di produksi).

Entry point memuat seluruh ekosistem dengan satu baris:

public/index.php

<?php
declare(strict_types=1);
 
require __DIR__ . "/../vendor/autoload.php";
 
$gateway = new App\Payment\Gateway();
var_dump($gateway->proses(50000));

#Semantic Versioning: Cara Membaca Batasan

Batasan versi di composer.json memakai semver (MAJOR.MINOR.PATCH):

Sintaks	Arti	Contoh pemakaian
`^1.2`	≥1.2, di bawah 2.0 (breaking dihindari)	`"phpunit/phpunit": "^11.0"`
`~1.2`	≥1.2, di bawah 1.3	Patch + minor terkunci
`>=1.0, <2.0`	rentang eksplisit	kasus khusus
`dev-main`	branch tertentu	bukan untuk produksi

Pertimbangan: pembaruan MINOR/PATCH seharusnya tidak breaking, sehingga ^ aman. Untuk PHP runtime sendiri, pin "php": "^8.5" agar fitur 8.5 dijamin ada (episode 16).

#Keamanan Dependensi: `composer audit`

Composer 2 punya scanner kerentanan bawaan:

Audit keamanan dependensi

composer audit
composer audit --locked

composer audit mencocokkan versi terinstall dengan database kerentanan (Security Advisories). Output:

Contoh hasil audit

2 package(s) have known vulnerabilities!
- symfony/http-client 6.4.8 has a vulnerability: CVE-2026-xxxxx ...
  Run composer update symfony/http-client to fix it.

Jadikan composer audit bagian dari CI (episode 19) — inilah garis pertahanan pertama keamanan supply chain, selain tema episode 17.

Warning

Jangan jalankan composer update tanpa alasan di produksi — versi bisa melompat jauh dan menimbulkan breaking change tak terduga. Untuk perbaikan keamanan, update package spesifik yang ditandai audit, lalu jalankan test suite.

#Common Pitfalls

composer.lock tidak di-commit — build tidak reproducible, bug muncul hanya di produksi.
composer install vs update tertukar — install dipakai untuk reproduce; update untuk mengubah dependensi.
Namespace tidak cocok folder — autoload PSR-4 gagal diam-diam; verifikasi dengan composer dump-autoload -o.
Package masuk require padahal hanya untuk dev — boros di produksi; pisahkan dengan require-dev.
Abaikan composer audit — dependensi lama berisiko; jadikan audit langkah rutin.

#Penutup

Inti yang harus dibawa pulang:

composer init/require/install/update adalah perintah inti; install untuk reproduce, update untuk mengubah.
composer.json = range versi; composer.lock = versi persis — commit keduanya.
PSR-4 memetakan App\ ke src/ sehingga autoload otomatis.
Pakai semantic versioning (^1.2) dan jalankan composer audit secara rutin.

Di episode 10 selanjutnya kita memastikan kualitas: Testing (PHPUnit/Pest) & Debug — struktur test, assertions, coverage, lalu Xdebug untuk step debugging, var_dump/dd(), dan static analysis PHPStan/Psalm. Mulai episode ini, setiap kode yang kalian tulis bisa dipertanggungjawabkan.