Autoloading

Introduction

Every example so far that used a library — like require 'vendor/autoload.php' before creating a new PHPMailer() — relied on autoloading. This lesson explains exactly how that single line makes every class in a project or its dependencies available without listing dozens of manual require statements.

You already learned namespaces earlier in this course. Autoloading is the piece that connects a namespace to an actual file on disk, automatically, the moment a class is used.

The Problem Autoloading Solves

Without autoloading, using a class defined in another file means manually requiring that file first — and every file that class depends on, and so on. In a small script this is manageable; in a real application with dozens or hundreds of classes, it quickly turns into an unmanageable wall of require statements that must be kept perfectly in sync with the codebase.

<?php
require 'classes/User.php';
require 'classes/Product.php';
require 'classes/Order.php';
require 'classes/Database.php';
require 'classes/Mailer.php';
// ...and one more line for every class the project ever adds

$user = new User();

PSR-4 Autoloading

PSR-4 is a PHP community standard that defines a predictable way to map namespaces to folders. Under PSR-4, a namespace prefix corresponds to a base directory, and the rest of a fully qualified class name maps directly onto a file path inside it.

Composer implements PSR-4 for you: once you tell it which namespace prefix maps to which folder, it generates an autoloader that resolves any class in that namespace to the right file automatically, without you writing a single require.

Configuring Autoload in composer.json

A project defines its own PSR-4 mapping inside the "autoload" section of composer.json. This tells Composer: "everything under the App\\ namespace lives inside the src/ folder."

{
    "name": "programinds/demo-app",
    "require": {
        "phpmailer/phpmailer": "^6.9"
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

With this mapping in place, a class file at src/Models/User.php should declare itself under the matching namespace.

<?php

namespace App\Models;

class User
{
    public function __construct(public string $name)
    {
    }
}

Running composer dump-autoload

Whenever the autoload configuration in composer.json changes — or you add new classes that follow an existing mapping — Composer needs to regenerate its internal lookup tables. That is what composer dump-autoload does.

composer dump-autoload

Generating autoload files
Generated autoload files

Including vendor/autoload.php

Composer generates a single file, vendor/autoload.php, which registers the autoloading logic for every dependency and for your own PSR-4-mapped classes. Including this one file, once, at the entry point of your application, is all that is needed for every class — yours and every installed package's — to become available on demand.

<?php

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

use App\Models\User;
use PHPMailer\PHPMailer\PHPMailer;

$user = new User('Alex');
$mail = new PHPMailer();

echo 'Loaded user: ' . $user->name;

Loaded user: Alex

Notice that neither User nor PHPMailer required an individual require statement. The moment PHP encounters new User(...), the autoloader steps in, works out the matching file from the namespace, and loads it automatically.

Autoloading and Namespaces

Autoloading only works because namespaces (covered earlier in this course) give every class a predictable, fully qualified name. PSR-4 is really just a formal agreement that a namespace segment corresponds to a folder segment, so tools like Composer can translate one into the other mechanically, without guessing.

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

Autoloading, powered by Composer and the PSR-4 standard, turns namespaces from an organizational convention into a fully automatic file-loading system. A single require of vendor/autoload.php replaces what would otherwise be dozens of manual require statements.

With dependency management and autoloading in place, you are ready to see how real applications organize their own code — starting with the next lesson's introduction to the MVC architectural pattern.