Laravel Vendor Cleanup Laravel Package

Product Decisions This Supports

• Whether shipped-artifact size is a product problem worth a ticket. This package only matters if someone owns a metric like deploy duration, container image size, registry egress, or package-size ceilings. If no such number exists on a dashboard, the PM finding is that gap — not this dependency.
• Distribution-model classification (the real decision). It earns attention when the artifact is the deliverable: on-prem/self-hosted installers, air-gapped media, Lambda/Bref bundles near the unzipped size ceiling, Docker images with registry budgets, or bandwidth-capped FTP/rsync deploys. It is close to noise for managed-PaaS SaaS where a few megabytes vanish into build minutes.
• Build vs. buy vs. ignore — and “ignore” is a legitimate outcome. The capability is essentially a pattern list applied to vendor/. A dependency is defensible only because maintenance cost is near zero; the alternative is inlining the rules into your own deploy script and dropping a supply-chain node. With 161 stars, zero dependents, a single maintainer, and a 1.315 overall score against an opportunity score of 0.29, this is recipe-grade tooling, not a platform investment.
• Release-engineering standardization. If you are standardizing a deploy pipeline, this slots in as one small step alongside --no-dev, --prefer-dist, optimized autoloader, .dockerignore, multistage builds, and slim base images. It should never be the headline lever or the only change in a release-engineering epic.
• Prioritization of engineering time. The highest-value version of this work is usually already free: composer install --no-dev --prefer-dist --optimize-autoloader plus a multistage Docker build. Fund that baseline first; treat vendor pruning as an increment only after the baseline is measured.
• Security/hygiene checkbox, held lightly. Fewer shipped test fixtures and example configs is a defensible bullet in a hardening review, but files under vendor/ are rarely web-reachable. Do not let it inflate a security roadmap.
• Use-case validation before roadmap commitment. Worth a spike only where you can attach real numbers: per-deploy transfer costs, slow-link deploy times, Lambda layer limits, registry storage line items.

When to Consider This Package

Consider it when:

• You ship the full vendor/ tree, no build stage prunes it, and size or deploy time is a measured pain point with a before-number to improve.
• The deployment target has a hard or expensive size constraint (Lambda/Bref ceilings, registry egress budgets, constrained upload links, on-prem media).
• The cleanup re-runs automatically on every build — a post-install Composer script or Docker builder RUN step. One-off manual runs silently regress on the next composer install.
• You have the appetite to audit the dependency graph for packages that read their own README, tests, or fixtures at runtime.
• Maintainer reputation is allowed to partially offset thin adoption signals (Barry van den Heuvel is a long-tenured, well-known Laravel contributor).

Look elsewhere when:

• The dependency-free baseline already captures most of the win. Do --no-dev --prefer-dist --optimize-autoloader, measure, then decide if anything is left.
• The driver is Docker image size — multistage builds, slim/distroless bases, .dockerignore, and layer ordering dominate; pruning READMEs is a rounding error by comparison.
• The driver is Lambda packaging — Bref’s own layer tooling is the right seam.
• You publish your own packages — .gitattributes export-ignore solves it upstream, permanently and once.
• The driver is cold-start latency — OPcache preloading and lazy classmaps move that needle; deleting docs does not.
• Your org gates on bus factor, vendor immutability, or build reproducibility. Lift the pattern list into your own script and own it.
• The package would be require-dev while production builds use --no-dev and you are unwilling to add a builder stage — the command simply won’t exist where you need it.

Core tradeoff to accept: cleanup mutates vendor/ after Composer has recorded state. installed.json no longer matches disk, composer install may re-download packages it believes are complete, and runtime breakage can surface only in production.

How to Pitch It (Stakeholders)

For executives: A single-purpose Laravel utility that strips tests, documentation, and CI config out of vendor/ after dependency installation, shrinking the deployed artifact. Cost to adopt is hours, not sprints; the ceiling is low but so is the risk. Expected savings are single-digit to low-double-digit megabytes and seconds of deploy time — meaningful only where artifact size or upload time is a first-class constraint (Lambda, on-prem distributions, bandwidth-capped hosting). Recommendation: a contained experiment in one pipeline with before/after numbers, not a platform initiative.

For engineering: One Artisan command plus a configurable pattern list in config/vendor-cleanup.php; it reads vendor/composer/installed.json to enumerate packages. Wire it into a post-install Composer script or Docker builder stage so it runs on every build — never manually. Guard two things: cleanup is a destructive mutation, so it must be idempotent and re-applied after every install/update; and audit dependencies that read their own docs, tests, or fixtures at runtime before enabling aggressive rulesets. Ordering matters: install → clean → autoload dump / package discovery / view and route caching. Watch the availability trap — if the package is require-dev and the runtime build uses --no-dev, run it in a separate builder stage. Start with default patterns, run the full suite and a smoke deploy against the pruned artifact, then expand. Keep a one-flag disable and a tested rollback to an unpruned artifact.

For finance/ops: Frame value against concrete cost drivers — container registry storage and egress, Lambda package ceilings that force awkward workarounds, deploy duration multiplied by deploys per day, and per-deploy transfer cost on bandwidth-constrained hosts. If none of those appear on a dashboard, the right answer is “not now,” and the engineering hour is better spent on --no-dev hygiene and multistage builds, which deliver more for less operational risk.

Recommendation: Pilot in one non-critical pipeline. Instrument artifact size and deploy duration before/after, and rehearse rollback so the failure path is boring. Promote to the standard deploy script only if the delta is measurable and repeatable, and re-validate after Composer dependency updates or Laravel upgrades. Otherwise adopt the dependency-free baseline and revisit only if a hard size constraint emerges.