Production Dependencies Guard Laravel Package

Technical Evaluation

Architecture fit: The package sits at the Composer dependency-management layer, not inside the Laravel runtime. For a Laravel/PHP estate, that is a good architectural fit: it acts as a build-time guardrail that keeps development-only packages out of require, reducing production dependency surface, container size, and supply-chain exposure without changing application code. It is not Laravel-specific, so it applies uniformly across Laravel services, packages, and legacy PHP applications that use Composer.

Integration feasibility: Feasible with low application-level effort. The main integration work is Composer plugin governance: allowing the plugin in allow-plugins, deciding whether it lives in require-dev or a global/CI Composer setup, and ensuring it runs in the dependency-change workflow. Existing repositories with dev packages already in require may need remediation before enforcement becomes clean.

Technical risk: The functional scope is narrow and valuable, but maturity risk is material. With 83 stars and 0 dependents, external validation is low. Key risks are Composer plugin API compatibility, maintainer responsiveness, unclear package-classification behavior, and CI-only enforcement. A plugin failure should not become a release blocker unless the team explicitly makes it one.

Key questions: Which Composer versions are supported, especially Composer 2.x plugin API changes? How does it classify a package as development-only: naming heuristics, Packagist metadata, explicit configuration, or a maintained list? Does it block composer require, composer update, composer install, or only specific commands? Can teams allowlist legitimate exceptions? How does it behave with private packages, path repositories, monorepos, and --no-dev production installs? Is the plugin safe to run in CI without network access? What is the expected failure mode: warn or hard fail?

Integration Approach

Stack fit: High at the Composer layer, zero at the Laravel framework layer. It complements existing Laravel practices such as composer validate, lockfile review, Dependabot/Renovate, and CI dependency checks. It should be positioned as a dependency-hygiene control, not as a runtime security control.

Migration path: Pilot in one or two Laravel repositories. Add the plugin as a development/CI dependency, configure allow-plugins, run it against the current composer.json to identify existing violations, remediate by moving dev-only packages to require-dev, then make the check required in CI. For organizations with many repositories, distribute the configuration through a shared CI template or Composer global setup rather than relying on manual per-repo adoption.

Compatibility: Verify PHP and Composer version support against the oldest and newest Laravel applications in scope. Laravel 8+ projects are generally Composer 2-based, so compatibility should be straightforward, but Composer plugin allowlisting and CI image versions must be tested. Production installs using composer install --no-dev will not load a require-dev plugin, which is acceptable because the guard belongs in development and CI workflows.

Sequencing: First validate behavior in a non-blocking audit mode if supported. Second, baseline and remediate existing require sections. Third, enforce in CI for dependency-changing pull requests. Fourth, add to repository templates and developer onboarding. Fifth, review quarterly alongside Composer upgrades and plugin releases.

Operational Impact

Maintenance: Low day-to-day maintenance, but the package should be pinned and reviewed before Composer upgrades. Because it is a small MIT-licensed plugin with limited adoption, the team should be prepared to fork or replace it if maintenance stalls. Treat it as a replaceable guardrail, not a critical platform dependency.

Support: Community-supported only; no vendor SLA. Internal ownership should sit with the platform engineering or developer-experience team that owns Composer standards and CI templates. Document the escalation path and exception process.

Scaling: Scales well conceptually across many Laravel/PHP repositories because it enforces a simple Composer rule. Operationally, scaling requires central CI templates, shared documentation, and a clear exception mechanism. Without that, each repository will drift in how and whether the guard is applied.

Failure modes: False positives can block legitimate production dependencies if classification is inaccurate. False negatives can occur if CI does not run the check or if developers bypass it locally. Composer plugin API changes or allow-plugins misconfiguration can prevent the plugin from loading. Existing violations can cause sudden CI failures during rollout. The plugin being absent in production installs means it does not protect against post-deployment manifest edits unless CI remains the enforcement point.

Ramp-up: Low for Composer-literate developers, likely hours rather than days for a pilot. Organizational ramp-up is moderate: teams need to understand why dev packages belong in require-dev, how to request exceptions, and how the CI check behaves. TPM should frame the package as one control in a broader dependency-governance process, with measured adoption and a clear fallback if the plugin proves unreliable.