Composer Validate

composer validate checks whether the manifest and lock file are structurally valid and highlights common packaging mistakes. It is a cheap check that belongs in local workflow and CI.

Working Knowledge

• Run composer validate --strict in CI when the project can meet strict validation.
• Fix schema errors before relying on dependency resolution.
• Investigate lock-file warnings rather than ignoring them.
• Keep package metadata accurate for reusable libraries.
• Run validation after merge conflicts in dependency files.

Run Validation Locally

composer validate --strict

Validation checks the manifest shape and reports lock-file consistency problems. Strict mode turns warnings into a non-zero exit code, which is useful in CI when the repository meets the stricter expectations.

Put It In The Project Gate

{
  "scripts": {
    "validate": "composer validate --strict",
    "check": [
      "@validate",
      "@test"
    ]
  }
}

Then developers and CI can run:

composer check

Follow the project's existing script names when adding a gate.

Know What Validation Does Not Prove

Validation does not prove that dependencies are secure, that installation works on the deployment runtime, or that the application still behaves correctly. Pair it with composer install, composer audit, static analysis, and tests.

In Application Work

Validation does not prove packages are safe or compatible. Pair it with install, audit, static analysis, and tests.

What To Check

Before moving on, make sure you can run strict validation, interpret lock consistency warnings, add validation to CI, and explain why it is only one part of the project gate.