Laravel Vendor Cleanup Laravel Package

Technical Evaluation

Architecture fit: Low-to-moderate and intentionally peripheral. barryvdh/laravel-vendor-cleanup is a build/deploy-time utility, not a runtime dependency. Its correct architectural slot is a single CI/CD or Docker builder-stage step: after composer install, before autoload dumping, package discovery, and config/route/view caching. It should not shape application architecture, sit on the production runtime path, or be treated as a platform capability. A TPM should frame it as a contained release-engineering optimization, not a strategic dependency.

Integration feasibility: Straightforward for a Laravel/Artisan-fluent team. Install, optionally publish config/vendor-cleanup.php, run vendor:cleanup with dry-run first, inspect deletions, then wire it into an automated post-install/build step. The main feasibility trap is availability: if the package is require-dev and the production build uses composer install --no-dev, the command will not exist in that stage. It must run in a builder stage or build host where dev dependencies are present, with the pruned artifact carried forward. That is a pipeline-design decision the TPM must settle before ticketing work.

Technical risk: Moderate and concentrated. The tool is destructive by design: it mutates vendor/ after Composer has recorded state, so installed.json may no longer match disk, later composer install runs may re-download packages Composer believes are intact, and dependencies that read their own docs, tests, fixtures, or example configs at runtime can break — often only in production. Ecosystem signals are thin: 161 stars, zero dependents, a single maintainer, and a low opportunity score against a modest overall score. Maintainer reputation partly offsets this, but the honest classification is recipe-grade tooling, not critical-path infrastructure. The upside is also modest: single-digit to low-double-digit megabytes and seconds of deploy time, which is usually a rounding error next to --no-dev, --prefer-dist, optimized autoloaders, and multistage builds.

Key questions:

• Which deployment target creates the actual pain: on-prem/air-gapped installers, Lambda/Bref package limits, Docker registry storage/egress, or bandwidth-capped FTP/rsync?
• What are the measured vendor/ size, artifact size, and deploy-duration deltas on our real dependency graph?
• Does the current release support our PHP/Laravel matrix, dry-run, exclusions, and configurable patterns?
• Can it run in the same stage as composer install --no-dev, or does it require a separate builder stage?
• Which dependencies read their own docs, tests, or fixtures at runtime, and who audits that?
• What is the rollback path to an unpruned artifact if a pruned build fails?
• Is adopting this dependency worth it versus inlining the pattern list into our own deploy script?

Integration Approach

Stack fit: Good for Laravel/PHP teams on Composer and Artisan, but only where artifact size or transfer time is a first-class constraint. It is useful when the artifact is the deliverable: self-hosted installers, air-gapped media, Lambda/Bref bundles, Docker images with registry budgets, or slow FTP/rsync deploys. It is near-worthless for managed-PaaS SaaS deployments where a few megabytes are noise, and actively wrong where vendor immutability or build reproducibility is a stated policy. The TPM should classify the deployment target before spending engineering time.

Migration path: Pilot, do not retrofit. Establish a dependency-free baseline first: composer install --no-dev --prefer-dist --optimize-autoloader, .dockerignore, multistage builds, and slim base images. Measure what that alone delivers. Then run cleanup against a disposable build artifact in one non-critical pipeline, execute the full test suite and a smoke deploy against the pruned tree, and compare numbers. Do not touch production hosts in the first pass. Rehearse rollback to an unpruned artifact before promotion is discussed.

Compatibility: Dependency-graph-specific rather than framework-specific, because the thing being pruned is third-party package contents. Validate against the exact PHP/Laravel matrix and the heaviest Composer dependencies. Pin the package version. Check its assumptions about vendor layout — it reads vendor/composer/installed.json — against the Composer version in use. Revalidate after meaningful composer update runs or framework upgrades; a dependency changing internal layout can shift cleanup from under-deletion to over-deletion without warning.

Sequencing:

1. Baseline: measure vendor/ size, artifact size, and deploy duration with --no-dev, --prefer-dist, optimized autoloader, and multistage build.
2. Add cleanup only in a throwaway CI job or Docker builder stage.
3. Enforce order: composer install → cleanup → autoload dump / package discovery / view and route caching.
4. Run unit, integration, and smoke tests against the pruned artifact, not the source tree.
5. Compare savings against build-time and validation overhead; record the result durably.
6. Promote through staging to production only if the delta is stable and repeatable.
7. Re-run validation after Composer dependency changes or Laravel upgrades.

Operational Impact

Maintenance: Low day-to-day but not zero. The recurring cost is ownership: validation, version pinning, release-watching, and revalidating the pruned vendor tree after dependency changes. Because adoption signals are thin and the maintainer is one person, the TPM should budget this as a small permanent tax on dependency review, not assume it is free because the command is simple.

Support: Community-supported open source with limited production evidence, no vendor backing, and no SLA. Internal documentation must state who owns the build step, how to disable it via config or pipeline toggle, and how to fall back to an unpruned artifact. Do not place it adjacent to anything a customer-facing SLA depends on without a tested rollback story. If the organization gates on bus factor, lift the pattern list into an internally owned deploy script and remove the supply-chain node.

Scaling: Not a runtime scaling concern; it does not affect request throughput. Its scaling relevance is build-time and distribution: larger dependency graphs, many deploys per day, registry storage/egress, Lambda package ceilings, and slow-link deploys. For most SaaS systems, the operational leverage is small; for artifact-distribution-heavy systems, it can be a minor but real lever.

Failure modes: Over-deletion breaking a dependency that reads its own fixtures/docs at runtime; non-idempotent or manually run cleanup silently regressing after the next composer install; the command being absent under --no-dev; cache/autoload ordering producing inconsistent artifacts; Composer re-download churn because installed.json no longer matches disk; and no tested rollback path. Each failure mode is manageable, but only if the pipeline runs cleanup automatically and the artifact is smoke-tested before production.

Ramp-up: Low technically, moderate organizationally. One Artisan command plus a config file is easy to learn; the real ramp-up is dependency auditing, pipeline placement, baseline measurement, and rollback rehearsal. A TPM should timebox this as a contained experiment in one pipeline, not a platform initiative. Promote only if the measured delta is repeatable; otherwise adopt the dependency-free baseline and revisit only when a hard size constraint emerges.