Composer and Package Management
Composer is the de facto dependency manager for PHP. Rather than manually downloading libraries and wiring up include/require statements, you declare your project's dependencies and their version constraints in a composer.json file, and Composer resolves a compatible set of package versions, downloads them into a vendor/ directory, and generates an autoloader that makes every installed class available without manual require statements.
Cricket analogy: Instead of a franchise scouting and signing every player individually and manually tracking eligibility, Composer works like the IPL auction system: you list required 'players' (packages) in composer.json, and it drafts a compatible squad into a vendor/ dugout with everyone's registration papers (autoloader) ready.
composer.json and semantic versioning
The require section of composer.json lists packages and version constraints using semantic versioning operators: ^8.1 allows any 8.x release at or above 8.1 but not 9.0, ~1.2 allows patch-level updates within 1.2.x, and an exact version like 3.4.0 pins precisely. Composer distinguishes require (production dependencies) from require-dev (tools only needed during development, like PHPUnit or a static analyzer), so production installs can exclude dev tooling entirely with --no-dev.
Cricket analogy: A team's playing-contract lists version-like conditions for each player: '^8.1' is like signing a player 'aged 25 or above but under 35' (any point release within the era), '~1.2' allows only minor form changes within a season, and an exact pick like '3.4.0' locks a specific player; net-practice-only coaches (require-dev) are dropped from the matchday squad (--no-dev).
{
"name": "acme/billing",
"description": "Billing domain package",
"type": "library",
"require": {
"php": ">=8.2",
"guzzlehttp/guzzle": "^7.8"
},
"require-dev": {
"phpunit/phpunit": "^11.0"
},
"autoload": {
"psr-4": {
"Acme\\Billing\\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"Acme\\Billing\\Tests\\": "tests/"
}
},
"scripts": {
"test": "phpunit"
}
}composer.lock and reproducible installs
While composer.json expresses acceptable version ranges, composer.lock records the exact resolved version of every package (and its own transitive dependencies) that was installed. Running composer install reads the lock file and installs precisely those versions, guaranteeing every developer and every CI run gets an identical dependency tree; composer update instead re-resolves against composer.json's constraints and rewrites the lock file. Committing composer.lock to version control is standard practice for applications.
Cricket analogy: composer.json is like a team's stated selection policy, while composer.lock is the actual matchday scorecard naming the exact XI and reserves who played; every venue (developer machine, CI) reading that scorecard fields the identical team, while calling for a fresh selection meeting (composer update) can change who's picked and rewrites the scorecard.
Running composer update instead of composer install in production or CI can silently pull in newer package versions than what was tested, since update ignores the lock file's pinned versions and re-resolves within your constraints. Deployment pipelines should almost always run composer install --no-dev to reproduce exactly what was tested.
PSR-4 autoloading
The autoload.psr-4 section maps namespace prefixes to directories, following the PSR-4 autoloading standard: a class Acme\Billing\Invoice maps to the file src/Invoice.php given the mapping above. Composer generates a vendor/autoload.php file that, once required at your application's entry point, transparently loads any class from any installed package (or your own project) on first use, without manual require statements anywhere in your code.
Cricket analogy: The autoload.psr-4 map is like a scorecard's team-to-dugout mapping: naming 'Acme\Billing\Invoice' finds the player in a specific spot (src/Invoice.php) the way naming 'Mumbai Indians #45' finds a specific player in a specific dugout row; once the master roster (vendor/autoload.php) is checked in, any player is found automatically the first time they're called on.
Packagist (packagist.org) is the default public package repository Composer searches when resolving package names like guzzlehttp/guzzle. Private packages can be served from a private Packagist instance, a VCS repository, or a local path repository, all configurable in the repositories section of composer.json.
- composer.json declares dependencies with semantic version constraints; require is for production, require-dev for tooling only.
- composer.lock pins exact resolved versions for reproducible installs across machines and CI.
- composer install respects the lock file; composer update re-resolves and rewrites it.
- PSR-4 autoload mappings in composer.json let Composer generate vendor/autoload.php for automatic class loading.
- Deployments should run composer install --no-dev to reproduce tested dependency versions without dev tooling.
- Packagist is the default public registry Composer resolves package names against.
Practice what you learned
1. What is the primary difference between composer.json and composer.lock?
2. Which command should typically be run in a deployment pipeline to reproduce exactly the dependency versions that were tested?
3. What does the version constraint ^7.8 in composer.json allow?
4. What does the autoload.psr-4 section of composer.json configure?
5. What is Packagist?
Was this page helpful?
You May Also Like
Autoloading with Composer
See how Composer's PSR-4 autoloader eliminates manual require statements by mapping namespaces to directories and generating an efficient class-loading map.
Unit Testing with PHPUnit
Get started with PHPUnit, PHP's most widely used testing framework, covering test case structure, assertions, data providers, and mocking dependencies.
Namespaces in PHP
Understand how PHP namespaces prevent naming collisions between classes, functions, and constants, and how import statements and resolution rules connect them across files.
The PHP Framework Landscape
A tour of the major PHP frameworks — Laravel, Symfony, and lighter-weight alternatives — and the trade-offs that determine which one fits a given project.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics