Composer Require Checker Laravel Package

Technical Evaluation

• Architecture fit: ComposerRequireChecker is a framework-agnostic Composer CLI analyzer, not a runtime Laravel package. It fits naturally as a CI quality gate in a Laravel/PHP stack because Laravel projects already rely on Composer for dependency resolution. It inspects an existing checkout after composer install and does not mutate code or install dependencies.
• Integration feasibility: High. It can be run as a PHAR, via PHIVE, or as a global Composer command with a single check invocation against the root composer.json. No application code changes are required. Laravel-specific configuration is mainly about scanning files outside Composer autoload paths, e.g. config/*.php, routes/*.php, bootstrap/*.php, and artisan, via the scan-files config section.
• Technical risk: Low-to-moderate. Primary risks are false positives from dynamic/conditional symbols, false negatives from unscanned Laravel paths, blind spots with custom Composer installer plugins, PHAR supply-chain handling, Xdebug-related performance/nesting issues, and PHP-version compatibility. The tool is mature enough for CI use but should be pinned and evaluated against the project’s PHP/Composer versions.
• Key questions: Will findings be advisory or blocking? Who owns the checker config and whitelist? Does the tool consider require-dev, or only runtime require? How will Laravel non-autoloaded paths be covered? How will PHAR versions be pinned and verified? What is the policy for existing soft dependencies and PHP extensions? How will custom installer plugins or monorepos be handled? What is the triage SLA for new findings?

Integration Approach

• Stack fit: Laravel projects use Composer, so the tool fits directly into existing CI pipelines after dependency installation. It is best placed as a dependency-hygiene step before or alongside tests. It does not need a running Laravel app, database, or queue worker.
• Migration path: Start with a pilot repository and run the checker in advisory mode to establish a baseline. Triage findings into true soft dependencies, missing extensions, and acceptable exceptions. Add explicit composer.json requirements where warranted, then codify exceptions in a checked-in composer-require-checker.json. Once clean, promote the CI job to blocking.
• Compatibility: Use the PHAR or PHIVE for reproducibility; avoid adding it to project dependencies. Verify PHP version support against the selected release, run with XDEBUG_MODE=off, and use Composer v2. For projects with custom installer plugins, run the scan after composer install --no-plugins as documented, or isolate the scan in a dedicated CI job.
• Sequencing: 1) Validate on one Laravel app, including scan-files for config/, routes/, bootstrap/, and artisan. 2) Capture baseline findings. 3) Fix or whitelist with owner sign-off. 4) Add CI as non-blocking. 5) Make blocking after two clean runs. 6) Standardize config across Laravel repos and review quarterly.

Operational Impact

• Maintenance: Low tool maintenance, but ongoing config ownership is required. Whitelist entries and scan-files globs will drift as the Laravel app evolves. Pin the PHAR version and upgrade deliberately after validating findings against the current dependency graph.
• Support: MIT-licensed community project with no commercial support. TPM should ensure an internal owner and a short runbook covering installation, config, triage, and exception approval. Rely on GitHub releases/issues for upstream fixes, and avoid blocking releases on unmaintained upstream behavior without a fallback.
• Scaling: Scales linearly per repository as a CI job. Runtime is usually acceptable for typical Laravel codebases when Xdebug is disabled. For many repos, cache Composer installs, run scans in parallel, and centralize config templates. It is not a runtime service and has no production traffic impact.
• Failure modes: Missing composer install, custom installer plugin layouts, un-scanned Laravel paths, false positives, whitelist misconfiguration, PHP version mismatch, Xdebug nesting/performance limits, PHAR download or integrity issues, and CI output parsing. Plan for advisory mode and a documented exception process before enforcing.
• Ramp-up: Low for engineers familiar with Composer; moderate for teams unfamiliar with soft vs. hard dependencies. Expect a short enablement session on dependency hygiene, config ownership, and triage workflow. Initial baseline cleanup may take one to two sprints depending on the number of existing soft dependencies.