intermediate15 min

Composer and Package Management

How composer.json declares dependencies and autoloading rules for a PHP project.

What you'll learn

  • Explain what `composer.json` declares for a PHP project
  • Describe what `composer install` does with the `vendor/` directory
  • Read a parsed composer.json-shaped structure and identify its key sections

Explanation

Composer is PHP's standard dependency and package manager. A project declares what it needs in a composer.json file: a "require" section lists other packages (and version constraints, like "^3.0") your code depends on, and an "autoload" section typically declares PSR-4 mappings -- which namespace prefixes correspond to which directories in your own code.

Running composer install reads composer.json, resolves compatible versions of every dependency (and their own dependencies), downloads them into a vendor/ directory, and generates vendor/autoload.php -- a single file that, once required with require "vendor/autoload.php";, makes every dependency's classes (and your own PSR-4-mapped classes) available to autoload automatically, with no manual require per class.

vendor/ is generated content, not something you hand-edit or typically commit to version control -- composer.json (what you depend on) and composer.lock (the exact resolved versions, for reproducible installs) are the files that matter for collaboration; anyone can regenerate vendor/ from those with composer install.

The structure below mirrors what a real composer.json file conceptually contains once read -- in an actual project this is a JSON file on disk, parsed by Composer's own tooling, not something your application code manually walks like this.

Guided lab

Predict: Reading a composer.json-shaped structure

PHPNot executed
This lab does not run in your browser or on VisaSparkSchools's servers. Read the code, predict what it does, then reveal the real expected output.

This mirrors the parsed shape of a composer.json file's key sections. Predict the output.

<?php
// This mirrors the parsed shape of a composer.json file after
// `composer install` reads it (real PSR-4 keys end in a namespace
// separator backslash; simplified to "App" here for clarity).
$composerConfig = [
    "name" => "visasparkschools/demo-app",
    "require" => [
        "monolog/monolog" => "^3.0",
    ],
    "autoload" => [
        "psr-4" => [
            "App" => "src/",
        ],
    ],
];

echo "Package: " . $composerConfig["name"] . "\n";
echo "Dependency: monolog/monolog " . $composerConfig["require"]["monolog/monolog"] . "\n";
foreach ($composerConfig["autoload"]["psr-4"] as $namespace => $dir) {
    echo "Namespace " . $namespace . " maps to " . $dir . "\n";
}

Stuck? Get a hint.

Common mistakes

  • Committing the `vendor/` directory to version control instead of just `composer.json` and `composer.lock` -- `vendor/` is regenerable, and committing it bloats the repository.
  • Editing files inside `vendor/` directly to "fix" a dependency -- any change is wiped out the next time `composer install` runs.
  • Confusing `composer.json` (what you depend on, with flexible version constraints) with `composer.lock` (the exact versions actually installed, for reproducibility).

Knowledge check

Knowledge check

1. What does `composer.json`'s `"require"` section declare?
2. What does `composer install` generate that lets classes autoload without manual `require` calls?
3. Should the `vendor/` directory typically be committed to version control?

Takeaway

`composer.json` declares dependencies and PSR-4 autoload mappings; `composer install` resolves and downloads them into `vendor/` and generates the autoloader -- commit the former, not the latter.

Summary

Composer manages PHP dependencies via composer.json (declared requirements and autoload rules) and composer.lock (exact resolved versions); `composer install` populates the regenerable vendor/ directory.

References

Your notes

Notes save automatically.

Finished this lesson?

Mark it complete to track your progress and schedule a future review.