Composer Cleanup Login Laravel Package

Product Decisions This Supports

• Deployment artifact strategy (build vs. buy vs. ignore). This plugin sits at the intersection of "how small do we make our production artifact" and "how much do we invest in that." It informs whether the team treats vendor/ bloat as a real cost line or an accepted constant. Relevant decisions: container image size budgets, Lambda/serverless package limits (50 MB zipped / 250 MB unzipped on AWS), shared-hosting disk quotas, and CI cache/transfer costs.
• Release velocity and rollback cost. Smaller artifacts mean faster image pulls, faster blue/green cutovers, and cheaper cold starts. If deploys are slow or expensive today, this is one lever among several (base image slimness, multi-stage builds, opcache preloading) — a PM should treat it as a tooling option in a portfolio, not a standalone initiative.
• Build vs. buy for internal tooling. The functionality is a handful of rm -rf patterns run as a Composer post-install script. The "buy" side is convenience and community-maintained file-pattern lists; the "build" side is ~20 lines in composer.json scripts plus a CI assertion. This package is a useful reference design for a decision you may end up building yourself.
• Supply-chain and platform-hardening roadmap. Composer plugins execute with full Composer privileges inside the build environment. Adopting one is a (small) expansion of the trusted computing base — a decision that belongs in the same conversation as dependency pinning, SBOM generation, and artifact signing.
• Use cases it genuinely serves: PHP apps deployed as immutable container images; monoliths with 100+ dependencies where vendor/ doc/test content is tens to hundreds of MB; serverless PHP (Bref) with hard package ceilings; regulated environments where reducing shipped source material marginally shrinks inspection surface.
• Use cases it does not serve: any question about product features, user-facing behavior, or customer experience. This package is invisible to end users by design. Do not attach it to a product roadmap narrative; attach it to a platform/DevOps cost story.

Diligence flag before deciding anything: the package identifier provided (barryvdh/composer-cleanup-login) does not match the linked repository (barryvdh/composer-cleanup-plugin). Zero stars, a score of 0, and zero dependents mean there is essentially no ecosystem validation. Resolve the naming discrepancy and confirm the actual maintained package before this enters any decision record.

When to Consider This Package

Consider it when:

• Your production artifact size is a measured, named problem — you can quote the MB of vendor/ attributable to tests/docs, and the corresponding deploy time or storage delta.
• Your dependency tree is large, stable, and mostly conventional (Symfony/Laravel-style packages that keep tests and docs in predictable top-level directories).
• You already run immutable, reproducible builds: the cleanup is deterministic, applied at image-build time, and verified by a smoke test in CI.
• You have an existing post-deploy verification step (autoload dump, route list, container boot test) that would catch a package whose runtime behavior depended on a file the plugin deleted.
• You are comfortable pinning the plugin to an exact version and owning the file-pattern allowlist yourself.

Look elsewhere (or skip it) when:

• You just want smaller images. Multi-stage builds with composer install --no-dev --prefer-dist --classmap-authoritative already exclude dev dependencies, and slimmer base images usually dominate the savings.
• Any dependency loads files at runtime from paths under tests/, docs/, .github/, or examples/ — common enough in packages that ship stubs, fixtures, migrations, language files, or sample configs. Silent production breakage is the failure mode here.
• You need vendor trees to remain byte-identical to composer.lock for audit, SBOM, or reproducible-build attestation purposes. This plugin intentionally breaks that property.
• The package's maintenance signal stays at zero (no stars, no dependents, no recent releases, Composer 2 plugin API compatibility unverified). An unmaintained Composer plugin can break composer install outright on a Composer upgrade — a build-time outage with no upstream fix.
• Your team has no PHP build ownership. The savings are real but modest, and the operational risk lands on whoever debugs the container at 2 a.m.

Adoption criteria, stated plainly: pin the exact version, fork it if the upstream is dormant, treat the cleanup pattern list as your configuration under code review, run the full test suite plus a container boot test against the cleaned artifact, and instrument artifact size in CI so the benefit is provable rather than assumed.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is a small, free Composer plugin that strips test suites and documentation out of third-party PHP libraries before they ship to production. It is not a user-facing feature and it will not move a product metric. It is a deploy-cost lever: depending on the dependency count, it can trim meaningful weight from the deployable artifact, which shows up as faster releases, lower storage and bandwidth spend, and cheaper cold starts on serverless PHP. Because the linked package shows no ecosystem traction and an unclear maintenance posture, my recommendation is not to adopt it as a dependency but to treat it as a design reference and reproduce its behavior in our own build pipeline — roughly a day of engineering, zero third-party build-time trust, and full control over what gets deleted. Decision ask: approve that small internal build task if and only if we first measure vendor/ bloat and confirm the savings justify it.

To engineering leads: The pattern is sound, the packaging is not. Execute it as a post-autoload-dump script we own, gate it behind a CI assertion that the container still boots and the app's smoke suite passes against the trimmed artifact, and publish the size delta to the build dashboard. Do not take a build-time dependency on a zero-adoption Composer plugin that runs with full Composer privileges unless we fork and maintain it deliberately. First step is a measurement spike, not an adoption.

To security/compliance: Composer plugins execute inside the build environment. This one mutates vendor/, which means the shipped tree no longer matches composer.lock byte-for-byte. If we require reproducible vendor trees for attestation or SBOM fidelity, this is disqualified on those grounds alone regardless of its functional merit.