Composer Scripts

Composer scripts let a project name common commands and run hooks around install and update events. They improve consistency but must be reviewed because they execute code.

Working Knowledge

• Use named scripts for checks such as tests, linting, and static analysis.
• Keep scripts understandable and documented through their names.
• Treat dependency-provided scripts and plugins as executable supply-chain surface.
• Avoid embedding secrets in script definitions.
• Know when deployment runs scripts and when --no-scripts is appropriate.

Name Repeatable Project Checks

{
  "scripts": {
    "lint": "php -l public/index.php",
    "analyse": "phpstan analyse",
    "test": "phpunit",
    "check": [
      "@lint",
      "@analyse",
      "@test"
    ]
  }
}

Run the combined gate with:

composer check

Install And Update Hooks

Composer supports events such as post-install-cmd and post-update-cmd. Frameworks may use them to clear caches, discover packages, or generate files.

These hooks can be useful, but they also execute code during installation. Read them before changing deployment behaviour or installing an unfamiliar project. Use --no-scripts only when you understand what the skipped scripts normally do.

In Application Work

A convenient hook can also surprise deployments. Check what runs automatically during install and update before changing production workflows.

What To Check

Before moving on, make sure you can define named checks, identify automatic hooks, and explain why scripts require supply-chain review.