composer and ecosystem

Understanding composer.json

composer.json is the project manifest. It describes package identity, dependency constraints, autoload rules, scripts, repositories, and configuration that Composer uses.

Working Knowledge

Keep require for runtime packages and require-dev for tools needed only during development.
Use autoload for production classes and autoload-dev for test-only namespaces.
Treat scripts and plugins as executable code during review.
Keep repository declarations deliberate, especially for private packages.
Run composer validate after editing the manifest.

A Small Application Manifest

{
  "require": {
    "php": "^8.3",
    "ext-json": "*",
    "monolog/monolog": "^3.0"
  },
  "require-dev": {
    "phpunit/phpunit": "^11.0"
  },
  "autoload": {
    "psr-4": {
      "App\\": "src/"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Tests\\": "tests/"
    }
  },
  "scripts": {
    "test": "phpunit"
  }
}

require lists runtime requirements, including PHP and extensions. require-dev contains tools needed for development and CI. The autoload sections map namespaces to directories.

Review Executable Configuration

Composer scripts and plugins can execute code. Review changes to these sections with the same care as PHP source code.

Private package repositories also deserve attention: check the URL, authentication method, ownership, and whether the repository is genuinely needed.

After editing the manifest, run:

composer validate --strict
composer dump-autoload

In Application Work

Read the existing manifest before adding keys. Framework projects often already define scripts, plugin policy, and namespace layout that new changes should follow.

What To Check

Before moving on, make sure you can read runtime, development, autoload, script, and repository sections and explain why scripts and plugins need review.

Practice

Practice: Add Project Autoloading

Extend the practice application manifest so source classes and test classes use separate PSR-4 mappings.

Requirements

Classify runtime and development packages.
Check PSR-4 mappings.
Review scripts and plugin configuration.
Run manifest validation.

Create src/Support/Slugger.php in namespace App\Support and tests/Support/SluggerTest.php in namespace Tests\Support. Run composer dump-autoload, then confirm the production class can be loaded through vendor/autoload.php.

Show solution

{
  "autoload": {
    "psr-4": {
      "App\\": "src/"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Tests\\": "tests/"
    }
  }
}

Then run:

composer validate --strict
composer dump-autoload
php -r "require 'vendor/autoload.php'; var_dump(class_exists('App\\\\Support\\\\Slugger'));"

The final command should print bool(true). Review scripts and plugin configuration separately because they may execute code during Composer operations.