Real‑world examples of using Composer for PHP dependency management

If you’re hunting for real, working examples of using Composer for PHP dependency management, you’re in the right place. Instead of abstract theory, this guide walks through concrete scenarios you’ll actually hit in modern PHP projects. These examples of Composer usage range from spinning up a tiny script with one library to orchestrating complex multi-environment applications. Composer has quietly become the standard for managing PHP dependencies, autoloading, and even project scaffolding. In 2024 and 2025, almost every serious PHP framework, from Laravel to Symfony, expects you to know how to use it. The best examples of day-to-day Composer usage are surprisingly small: installing a single HTTP client, locking versions for production, or wiring up PSR‑4 autoloading for your own code. We’ll walk through those real examples step by step, including how to read `composer.json`, how to run `composer update` without wrecking production, and how to use Composer scripts to automate boring tasks.
Written by
Jamie
Published
Updated

Quick, concrete examples of using Composer for PHP dependency management

Let’s start with hands-on scenarios instead of definitions. Here are real examples of using Composer for PHP dependency management that mirror what you’ll do on actual projects.

Example of creating a new Composer-based PHP project

You’ve got a fresh server or a new Git repo and want to bootstrap a modern PHP project. One of the best examples of using Composer for PHP dependency management is the initial project setup.

## Initialize a new Composer project interactively
composer init

You’ll be prompted for package name, description, license, and dependencies. After answering, Composer generates a composer.json like this:

{
  "name": "acme/example-app",
  "description": "Simple PHP app using Composer",
  "require": {
    "php": ">=8.1",
    "guzzlehttp/guzzle": "^7.9"
  },
  "autoload": {
    "psr-4": {
      "Acme\\App\\": "src/"
    }
  }
}

Then you install dependencies:

composer install

This creates a vendor/ directory and a vendor/autoload.php file. Now you can write a tiny script that uses Guzzle:

<?php
require __DIR__ . '/vendor/autoload.php';

use GuzzleHttp\\Client;

$client = new Client();
\(response = \)client->get('https://api.github.com');

echo $response->getStatusCode();

This is one of the cleanest examples of using Composer for PHP dependency management: define dependencies once, install, then autoload everything without manual require calls.


Real examples of adding and updating dependencies with Composer

Once a project exists, the daily grind is adding, updating, and removing packages. These are the examples of Composer usage you repeat all year.

Example of adding a new library to an existing project

Say you want to send HTTP requests from a legacy project that’s finally using Composer. You can add Guzzle like this:

composer require guzzlehttp/guzzle:"^7.9"

Composer will:

  • Update composer.json with the new dependency
  • Install the library into vendor/
  • Update composer.lock with exact versions

You then use it immediately:

<?php
require __DIR__ . '/vendor/autoload.php';

$client = new GuzzleHttp\\Client([
    'timeout' => 5.0,
]);

\(response = \)client->get('https://httpbin.org/get');
\(data = json_decode(\)response->getBody()->getContents(), true);

var_dump($data);

This is one of the best examples of using Composer for PHP dependency management in practice: a single command gives you a production-ready HTTP client with zero manual configuration.

Example of updating dependencies safely in 2024–2025

The scary part is updating. You want security patches, but not surprise breaking changes. A real example of a safer workflow:

## See outdated packages
composer outdated

## Update only a specific package
composer update monolog/monolog

## Or update only within allowed constraints
composer update --with-all-dependencies

You commit both composer.json and composer.lock, then run your automated tests. In 2024–2025, pairing Composer updates with CI (GitHub Actions, GitLab CI, etc.) is standard practice, especially as PHP 8.3+ features roll into libraries.

For security guidance, many teams also track advisories via tools like the GitHub Advisory Database or vendor security feeds, then use Composer to bump versions quickly when a CVE drops.


Examples of using Composer for PHP dependency management with PSR‑4 autoloading

Composer isn’t just about third-party code. One of the most useful examples of using Composer for PHP dependency management is letting it autoload your classes.

Example of wiring PSR‑4 autoloading for your namespace

In composer.json:

{
  "autoload": {
    "psr-4": {
      "Acme\\App\\": "src/"
    }
  }
}

Your directory structure might look like:

src/
  Controller/
    HomeController.php
  Service/
    UserService.php

HomeController.php:

<?php

namespace Acme\\App\\Controller;

class HomeController
{
    public function index(): string
    {
        return 'Hello from HomeController';
    }
}

After setting up autoloading, you run:

composer dump-autoload

Now you can use your classes anywhere:

<?php
require __DIR__ . '/vendor/autoload.php';

use Acme\\App\\Controller\\HomeController;

$controller = new HomeController();
echo $controller->index();

This example of Composer autoloading shows how you avoid manual require spaghetti and keep your PHP code organized around namespaces.


Best examples of using Composer scripts to automate workflows

Composer scripts are underrated. They let you attach commands to names and run them consistently across your team.

Example of defining and running Composer scripts

In composer.json:

{
  "scripts": {
    "test": "phpunit",
    "lint": "php -l src/*.php",
    "fix": "php-cs-fixer fix"
  }
}

You can now run:

composer test
composer lint
composer fix

Real examples include:

  • Running a test suite before every push
  • Generating code coverage reports
  • Running static analysis (phpstan, psalm)

For instance, a slightly more advanced scripts section:

{
  "scripts": {
    "analyse": "phpstan analyse src --level=max",
    "check": [
      "@lint",
      "@analyse",
      "@test"
    ]
  }
}

Now composer check becomes your one-liner quality gate. This is one of the best examples of using Composer for PHP dependency management beyond just installing libraries; it standardizes developer workflows.


Real examples of using Composer in frameworks (Laravel, Symfony, WordPress)

Frameworks are where the most visible examples of using Composer for PHP dependency management live.

Laravel project created via Composer

A classic real example:

composer create-project laravel/laravel blog-app "^11.0"

Composer downloads the Laravel skeleton, installs dependencies, and wires autoloading. Inside that project, you might add a queue driver or logging tool with:

composer require predis/predis

Laravel automatically discovers many packages via service providers and configuration files, so Composer becomes the gateway for the entire ecosystem.

Symfony skeleton with Composer

Another example of using Composer for PHP dependency management is bootstrapping a Symfony app:

composer create-project symfony/skeleton my-api

Then you add components as needed:

composer require symfony/http-client symfony/serializer

These examples include both framework-level dependencies and your own code, all managed via the same composer.json file.

Composer in modern WordPress development

Even though classic WordPress sites often ignore Composer, modern setups don’t. A real example:

composer require wpackagist-plugin/contact-form-7

Using wpackagist.org as a bridge, you manage WordPress plugins as Composer dependencies. This helps you:

  • Lock plugin versions in composer.lock
  • Rebuild environments consistently
  • Track changes to plugins in version control

This is one of the more interesting examples of using Composer for PHP dependency management in 2024–2025, especially for teams treating WordPress as part of a larger application stack.


Examples of Composer usage in multi-environment deployments

Real applications run in local, staging, and production environments. Composer needs to behave differently in each.

Example of separating dev and production dependencies

In composer.json:

{
  "require": {
    "php": ">=8.1",
    "monolog/monolog": "^3.6"
  },
  "require-dev": {
    "phpunit/phpunit": "^11.0",
    "phpstan/phpstan": "^1.12"
  }
}

On your laptop, you install everything:

composer install

On production, you install without dev packages:

composer install --no-dev --optimize-autoloader

This example of using Composer flags shows how you:

  • Keep production images smaller
  • Avoid shipping test tools and analyzers to live servers
  • Get faster autoloading via optimization

In containerized environments, teams often run composer install during image build, using --prefer-dist and --no-dev for reproducible builds.

Example of locking dependencies with composer.lock

Another real example of using Composer for PHP dependency management is relying on composer.lock as the single source of truth.

  • Developers run composer install using the committed lock file
  • CI uses the same lock file to run tests
  • Production deploys also run composer install rather than composer update

This means everyone runs exactly the same versions. You only run composer update intentionally, review the diff in composer.lock, and then commit.

For teams concerned with software supply chain integrity, this pattern lines up with general guidance from security-focused organizations (for example, see the broader software supply chain recommendations from CISA.gov and related federal guidance on dependency management).


Advanced examples of using Composer for PHP dependency management

Once you’re comfortable with the basics, there are more advanced examples of Composer usage that show up in larger organizations.

Example of using private repositories

Many companies host internal libraries. Composer can talk to private Git repos or artifact repositories.

{
  "repositories": [
    {
      "type": "vcs",
      "url": "git@github.com:acme/internal-logger.git"
    }
  ],
  "require": {
    "acme/internal-logger": "^2.0"
  }
}

Composer will fetch from your private Git repository using SSH keys. This example of a custom repository setup lets you treat internal code exactly like public packages.

Example of using stability flags and minimum-stability

If you’re experimenting with libraries that haven’t tagged stable releases, you might see examples include minimum-stability:

{
  "minimum-stability": "dev",
  "prefer-stable": true,
  "require": {
    "vendor/new-lib": "dev-main"
  }
}

This tells Composer to prefer stable releases but allow dev versions when explicitly requested. This example of configuration is common in early-stage projects or when contributing to libraries that haven’t cut a stable tag yet.

Example of using Composer in a monorepo

In a monorepo, you might have several PHP packages:

packages/
  Api/
  Web/
  Shared/

Each package has its own composer.json, but you can wire local paths:

{
  "repositories": [
    {
      "type": "path",
      "url": "../Shared",
      "options": {
        "symlink": true
      }
    }
  ],
  "require": {
    "acme/shared": "*"
  }
}

This example of a path repository lets Api depend on Shared without publishing to Packagist, while still using Composer’s versioning and autoloading.


FAQ: common questions and short examples of Composer usage

What are some simple examples of using Composer in a small PHP script?

A very small example of Composer in action:

composer require nesbot/carbon:"^3.0"

Then:

<?php
require __DIR__ . '/vendor/autoload.php';

use Carbon\\Carbon;

echo Carbon::now()->toDateTimeString();

This shows how you can bring in a high-quality date/time library with a single command.

Do I always need to commit vendor/ if I’m using Composer?

In most modern PHP projects, no. The common pattern is to commit composer.json and composer.lock, but ignore vendor/ via .gitignore. Your CI and servers then run composer install to rebuild vendor/. Some teams in tightly controlled environments still commit vendor/, but that’s more of an operational decision than a Composer requirement.

Can you give an example of using Composer only for autoloading my own code?

Yes. Even if you don’t use third-party libraries, you can set up autoloading:

{
  "name": "acme/internal-only",
  "autoload": {
    "psr-4": {
      "Acme\\Internal\\": "src/"
    }
  }
}

Then run composer dump-autoload and include vendor/autoload.php in your entry point. This example of Composer usage gives you modern autoloading without any external dependencies.

Where can I learn more about safe dependency practices?

For high-level guidance on software dependency risk (not PHP-specific), look at:

While these don’t talk about Composer directly, the principles—pin versions, track changes, audit dependencies—map directly onto the examples of using Composer for PHP dependency management in this article.


In practice, the best examples of using Composer for PHP dependency management are the ones you repeat: initializing projects, adding libraries, wiring autoloading, and keeping versions under control. Once those habits are in place, the more advanced real examples—private repos, monorepos, and CI workflows—start to feel like natural extensions rather than exotic features.

Explore More PHP Code Snippets

Discover more examples and insights in this category.

View All PHP Code Snippets