Composer Cleanup Login Laravel Package

Technical Evaluation

What this actually is. Despite the "Laravel/PHP package" framing, this is not a Laravel library and it adds nothing to the application runtime. It is a Composer plugin (type: composer-plugin) that subscribes to Composer's post-install-cmd / post-update-cmd lifecycle events and deletes files — tests, documentation, .git directories, example configs — from the vendor/ tree after dependency resolution. Its only product is a smaller vendor/ directory, which matters for container image size and artifact storage, not for application behavior.

Naming discrepancy — resolve before anything else. The supplied package identifier is barryvdh/composer-cleanup-login, but the repository is barryvdh/composer-cleanup-plugin. One of these is wrong, or the package is a fork/rename of the upstream. This must be reconciled against Packagist before any evaluation proceeds; a mismatched identifier is a supply-chain question, not a typo to shrug off.

Architecture fit. Adjacent to the application, embedded in the build. It sits in the same architectural layer as composer install --no-dev, Docker multi-stage builds, and .gitattributes export-ignore. It is orthogonal to Laravel's service container, autoloading, and framework conventions, so there is no framework-fit question — only a build-pipeline-fit question.

Integration feasibility. Mechanically trivial: add as a dev/build dependency, enable via Composer 2.2+'s config.allow-plugins, optionally supply a config file of include/exclude patterns. Roughly a half-day spike. The friction is entirely governance: Composer 2 requires an explicit allow-list entry per plugin, which is a deliberate supply-chain control that this package asks you to loosen for a tool with no adoption.

Technical risk. This is a destructive, non-idempotent post-processing step operating on resolved dependencies:

• Compliance exposure. Cleanup plugins typically strip LICENSE, COPYING, and NOTICE files along with docs. Many OSS licenses require redistribution of copyright notices. If you ship container images or artifacts externally, this is a legal-review item, not a size optimization.
• Silent over-deletion. A minority of packages lazily require fixture files, JSON schemas, or doc-adjacent resources at runtime. Failures surface late and are hard to trace back to a build step.
• Composer API coupling. Pinned to a composer-plugin-api range; Composer 3 will require a fork or replacement.
• Signal quality. Score 0, zero stars, zero dependents. The author (barryvdh) has genuine Laravel credibility, but reputation does not transfer to an unmaintained build plugin.

Key questions to answer before a decision.

1. Is this repository archived or superseded? What is the last commit and last tagged release?
2. Which composer-plugin-api versions does it declare, and does it work on our pinned Composer version?
3. Does it delete license files by default, and is that configurable?
4. How much actual size does it save versus --no-dev plus a multi-stage Docker build on our dependency set?
5. Is the identifier on Packagist the same package as the repository under review?

Integration Approach

Stack fit. Compatible with any PHP 7/8 + Composer 2 project, Laravel or otherwise. It belongs exclusively in the CI/deployment image build stage — specifically the layer that runs composer install --no-dev --prefer-dist. It must not be enabled in developer environments or anywhere dependency test suites are executed, since it removes the test files those suites depend on.

Migration path. Purely additive; there is no data or code migration. Adoption is a Dockerfile/composer.json edit and removal is a revert. This is the package's one genuine strength — the blast radius of a rollback is essentially zero, provided it is confined to a build stage.

Compatibility gates to verify.

• composer-plugin-api constraint against your pinned Composer version.
• config.allow-plugins entry — and whether your org permits build-time plugins at all.
• Interaction with other plugins that mutate vendor/ (patch plugins, installers). Ordering is not guaranteed; two tools editing the same tree is a real conflict surface.
• Reproducibility: the resulting vendor/ must be byte-identical across CI and production, or you have introduced environment drift for a size win.
• autoload.files and classmap entries pointing into directories being pruned.

Sequencing.

1. Reconcile package identity and confirm maintenance status.
2. Establish a baseline: current image size with --no-dev --prefer-dist and a multi-stage build.
3. Run a throwaway build with the plugin enabled; capture the size delta and diff the vendor/ tree.
4. Have legal/security confirm license-file removal is acceptable.
5. If the delta is under roughly 5% of image size, stop — the supply-chain cost exceeds the benefit.
6. If adopted: pin an exact version, allow-list only that plugin, and add a CI assertion that licenses remain present.

Operational Impact

Maintenance. Effectively self-supported. Zero stars and zero dependents means no upstream issue traffic, no community regression testing, and no realistic expectation of a timely fix if Composer changes its plugin API. Budget for owning a fork. The author's other projects being healthy is not evidence about this one.

Support. Community-only, no SLA, no security disclosure process to speak of. Contrast with the alternative — a five-line find/rm in a Dockerfile — which has an owner you already know and no external dependency.

Scaling. Technically negligible cost: a linear file walk over vendor/, seconds at most, and it reduces image pull time and registry storage proportionally to dependency count. The benefit scales with fleet size and deploy frequency, which is precisely why it deserves a measured number rather than an assumption.

Failure modes.

• Build succeeds, application fails at runtime on a missing fixture or schema file — late, expensive, hard to attribute.
• License/notice files absent from a distributed artifact — audit or compliance finding.
• vendor/ differs between environments because the plugin ran in one pipeline and not another — nondeterministic behavior with no visible cause.
• Composer blocks the plugin via allow-plugins, breaking the build on a Composer upgrade.
• Docker layer caching preserves a stale cleaned vendor/ after dependency changes.

Ramp-up. Low engineering effort — hours, not days. The real cost is governance: a security review, an allow-plugins exception, a legal sign-off on license stripping, and permanent ownership of an unmaintained fork. That overhead is disproportionate for a package with no adoption signal.

Recommendation. Do not adopt as a dependency. If image size is a genuine constraint, achieve the same outcome with the mechanisms already in the toolchain — --no-dev --prefer-dist, multi-stage Docker builds, .dockerignore, and an explicit, reviewable cleanup command in the build stage that preserves license files. That delivers comparable savings with no new supply-chain surface, no plugin API coupling, and no orphaned dependency. Reserve reconsideration only if a measured baseline shows a double-digit percentage size reduction that cannot be reached any other way.