Composer - The Tool That Saved PHP's Soul

Learn this or break production: composer install uses the lock file and installs the exact versions you tested with. composer update ignores the lock file, pulls whatever versions it wants, and will absolutely break something.In production? Always use install. Want to update packages? Use update locally, test everything, then commit the new lock file. I once watched a coworker run composer update directly on prod because "it was just a small fix." Took down the entire e-commerce site for 3 hours because Guzzle 7.2.0 broke our payment API calls. That was an awkward explanation to the CEO.

Hell no. Never commit the vendor/ directory to Git

• it's sacred. That shit will make your repo massive and create merge conflicts from hell. Every git pull becomes a nightmare of binary conflicts in random dependencies.Commit composer.json and composer.lock, add vendor/ to .gitignore, and let composer install recreate it. This is not negotiable. If someone on your team commits the vendor directory, fire them.

Because Composer's error messages are useless and it's basically saying "something's fucked, figure it out yourself." This usually means:

• Two packages want different versions of the same dependency (dependency hell is back!)
• Your PHP version is too old for what you're trying to install
• You're out of memory (classic Composer move)
• Some package has insane version constraintsTry composer why-not package/name version to see what's blocking a specific package.

Or composer update --dry-run --verbose for slightly less useless error messages. I spent an entire weekend debugging dependency conflicts before someone on Stack Overflow mentioned the --dry-run flag. Felt like an idiot. Pro tips for debugging dependency hell:

• composer depends vendor/package shows what depends on a package
• composer prohibits vendor/package shows what prevents installation
• composer show -t gives you a dependency tree
• Sometimes you just have to delete composer.lock and start over (nuclear option)

composer update vendor/package-name updates just that package. For example: composer update monolog/monolog. This is way safer than updating everything at once and breaking half your project.Add --with-dependencies if you want its dependencies updated too. Sometimes this works great, sometimes it pulls in 47 other updates and breaks everything anyway. There's no winning with dependency management.

require is for stuff your app needs to actually work

• frameworks, database libraries, that kind of thing. require-dev is for development tools
• testing frameworks, code formatters, debugging tools.

In production, use composer install --no-dev --optimize-autoloader to skip development packages and generate optimized class maps. This makes deployments faster and reduces attack surface (one less reason for security teams to hate you).Other production tricks that matter:

• --no-dev skips dev dependencies (obvious but critical)
• --optimize-autoloader generates class maps for faster autoloading
• --no-scripts prevents potentially dangerous post-install scripts

Private packages are a pain in the ass, but you have options:

• Private Packagist
• costs money but works
• Point directly to your Git repos in composer.json (free but annoying to set up)
• Satis
• roll your own package server (for masochists)
• Local path repositories for internal libs ("type": "path")Each option has trade-offs. Private Packagist is easiest if you have budget. Git repos work but authentication is a nightmare.

If you're still on Composer 1, you're officially screwed.

Upgrade to Composer 2 immediately

• it's way faster and will save your sanity. I know a guy still running 1.10.22 on a legacy project because "if it works, don't touch it." That's going to bite him in the ass eventually.Other tricks:

• composer install --no-dev in production (skips development packages)

• Enable OPcache (makes everything faster)

• composer dump-autoload --optimize for production (generates class maps)

• Use a fast SSD (dependency resolution hammers disk I/O)Even with Composer 2, large projects still take time. That's just the price of having hundreds of thousands of packages to choose from.

Create a composer.json file in your project root with required fields:json{"name": "vendor/package-name","description": "Package description", "type": "library","require": {"php": ">=8.0"}}Then submit your Git repository to Packagist for automatic crawling and distribution.

Composer scripts allow you to define custom commands in composer.json that can be triggered with composer run-script.

Common uses include:

• Running tests: "test": "phpunit"
• Code formatting: "cs-fix": "php-cs-fixer fix"
• Building assets: "build": "npm run prod"Scripts can trigger at specific events like post-install-cmd or pre-update-cmd.

Composer eats RAM like Chrome eats browser memory.

When you see "Fatal error: Allowed memory size exhausted," try:

• php -d memory_limit=2G composer.phar install (nuclear option
• give it all the RAM)
• composer install --no-dev (skip dev dependencies to save memory)
• composer clear-cache (sometimes helps, usually doesn't
• but worth trying)
• Upgrade to Composer 2 (uses less memory)If you're on shared hosting, you're probably fucked. I had one project that needed 3GB just to install dependencies. The $5/month hosting wasn't cutting it.

Absolutely!

Composer is framework-agnostic and works with any PHP project. Popular frameworks using Composer include:

• Symfony
• Laminas (formerly Zend Framework)
• CakePHP
• Drupal
• WordPress (with Bedrock)
• Or pure PHP projects without frameworks

Common autoloading problems and solutions:

• Run composer dump-autoload after adding new classes
• Ensure your namespace matches your directory structure (PSR-4)
• Check that class names match file names exactly
• Verify the autoload section in composer.json is configured correctly
• Use composer dump-autoload --optimize for production to generate classmaps