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
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
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.
AI tutor
The optional AI tutor isn't enabled in this deployment. All lessons, exercises, quizzes, and search work fully without it.