devsetup1-7 Exercise 2: A Composer Project ============================================ STEPS ----- sudo apt install composer git unzip # if not already installed composer --version mkdir -p ~/projects/composer-demo && cd ~/projects/composer-demo composer init --no-interaction --name="me/composer-demo" composer require monolog/monolog ls # composer.json composer.lock vendor Create app.php: pushHandler(new StreamHandler('php://stdout')); $log->info('Hello from Composer on ' . gethostname()); Run it: php app.php # a log line such as: [2026-09-30T12:00:00.000000+00:00] demo.INFO: Hello from Composer on devserver [] [] Now prove vendor/ is disposable: rm -rf vendor php app.php # fails: Failed opening required 'vendor/autoload.php' composer install php app.php # works again Add a .gitignore containing: vendor/ INSTALL VS UPDATE ----------------- composer install Reads composer.lock and installs EXACTLY the versions recorded there. If there is no lock file it resolves versions and creates one. The result is the same on every machine, which makes it the right command for rebuilding a project or deploying it. composer update Ignores the lock file, fetches the newest versions that composer.json allows, installs them, and REWRITES composer.lock. Use it when you deliberately want to upgrade, then test, then commit the new lock file. WHAT TO COMMIT -------------- Commit: composer.json, composer.lock, your own code, and .gitignore. Do not commit: vendor/. It is large, it is rebuilt from the lock file, and committing it makes the history noisy. WHY THIS WORKS AS AN ANSWER --------------------------- Deleting vendor/ and getting it back shows that the lock file, not the folder, is the record of the project's dependencies. The install/update distinction is the same one as npm ci and npm install in Chapter 6.