- What does barryvdh/composer-cleanup-login actually do?
- It is a Composer plugin that tidies up Composer's stored repository login credentials by removing leftover HTTP basic auth entries from Composer's auth configuration. Those stale entries typically accumulate when hosts are decommissioned, tokens are rotated, or private repositories are removed from a project. The goal is a clean credentials file with no orphaned tokens. It is a build-time utility, not a Laravel runtime library, so it adds nothing to your application code.
- How do I install barryvdh/composer-cleanup-login?
- Add it with Composer as a development or build dependency, for example composer require --dev barryvdh/composer-cleanup-login. Because Composer 2.2 and later block plugins by default, you must also add an allow-plugins entry for it in your root composer.json config section. Once allowed, it hooks into Composer's command lifecycle and runs automatically. Verify the package name on Packagist before installing, since the repository linked in the docs is named composer-cleanup-plugin rather than composer-cleanup-login.
- Does this package work with Laravel 10 and Laravel 11?
- The plugin is framework-agnostic: it does not touch Laravel's service container, autoloading, or service providers, so Laravel version is irrelevant to whether it works. What matters is your PHP version and your Composer version, because the plugin declares a composer-plugin-api constraint. It is compatible with any PHP 7 or PHP 8 project running Composer 2. Check the declared composer-plugin-api range against your pinned Composer release before adopting it.
- Why would Composer's auth config contain stale login credentials?
- Credentials linger when a private repository is removed from composer.json but its host entry stays in auth.json, or when a token is rotated and the old HTTP basic auth record is never purged. CI secrets injected via COMPOSER_AUTH can also leave residue when the same machine or image is reused. Over time these orphaned entries become a hygiene and audit problem, especially in shared build agents. The plugin exists to sweep those leftovers out automatically.
- Will the plugin delete credentials I still need, such as my private repository tokens?
- Any tool that edits your auth configuration deserves caution, so back up auth.json and test on a throwaway project first. Review exactly which entries the plugin considers stale before enabling it on a machine that authenticates to private packages, since an over-eager removal will break composer install with authentication errors. Running it in a controlled CI or build stage limits the blast radius, because the change is confined to that environment. If your auth config is generated entirely from environment variables, there is usually nothing to clean up anyway.
- Why do I have to add it to config.allow-plugins in Composer 2?
- Composer 2.2 introduced config.allow-plugins as a deliberate supply-chain control, requiring an explicit allow-list entry for every plugin that executes code during install or update. Adding this package means loosening that control for a plugin with essentially no adoption signal, so treat it as a governance decision rather than a routine dependency. In an organisation that restricts build-time plugins, this may need sign-off. If your policy forbids third-party Composer plugins, a short custom script that rewrites auth.json may be the safer alternative.
- Is barryvdh/composer-cleanup-login the same package as barryvdh/composer-cleanup-plugin?
- They are not the same thing as documented: the linked repository, composer-cleanup-plugin, is a vendor-directory cleanup tool that removes tests and documentation to save space, while the identifier under review is composer-cleanup-login, which targets stored repository credentials. That mismatch must be reconciled against Packagist before you install anything, because a package name that does not match the repository you reviewed is a supply-chain question rather than a typo. Confirm the exact vendor and package name, the tagged releases, and that the source link on Packagist points to the code you evaluated.
- Is it safe to strip tests and documentation from the vendor directory in a production build?
- Usually yes, but there are two real risks worth checking. First, a minority of packages lazily load fixture files, JSON schemas, or doc-adjacent resources at runtime, and those failures surface late and are hard to trace back to a build step. Second, many open-source licenses require you to retain copyright notices, so removing LICENSE, COPYING, or NOTICE files can create compliance exposure if you distribute container images or artifacts externally. Treat license-file removal as a legal review item and configure include and exclude patterns accordingly.
- How much space does it actually save compared with composer install --no-dev and a multi-stage Docker build?
- That depends entirely on your dependency set, and the honest answer is usually less than expected once you are already using --no-dev with --prefer-dist and copying only the built artifact into a slim final image. Before adopting anything, measure the vendor directory size on a real build with and without cleanup. If the gain is a few megabytes against a base image of hundreds, the added build complexity and plugin permission are hard to justify. Run the comparison as a short spike rather than assuming a benefit.
- Is this plugin maintained, and will it work with Composer 3?
- Public signals are weak: the repository has no stars and no dependents, so there is little community pressure to keep it current, and the author's Laravel credibility does not transfer to an unmaintained build plugin. Check the last commit date, the most recent tagged release, and the declared composer-plugin-api constraint before relying on it. Because it couples directly to Composer internals, Composer 3 will likely require a fork or replacement. If you adopt it, pin the version and plan an exit path such as a small in-house script.