Composer Cleanup Login Laravel Package

Getting Started

This is a Composer plugin, not a Laravel service provider — it hooks Composer's package-install events and deletes tests, docs, and CI files from vendor/ after they're extracted. Nothing is registered in config/app.php and nothing is autoloaded at runtime.

1. Require it as a dev dependency:

   composer require --dev barryvdh/composer-cleanup-plugin
   

2. Approve the plugin (Composer 2.2+). Composer will prompt; the resulting entry looks like:

   "config": {
       "allow-plugins": {
           "barryvdh/composer-cleanup-plugin": true
       }
   }
   

3. Configure the patterns in composer.json (the plugin ships sensible defaults; override them under extra):

   "extra": {
       "cleanup": {
           "ignore": [
               "*.md",
               "*.txt",
               "tests/",
               "test/",
               "docs/",
               "examples/",
               "phpunit.xml*",
               ".travis.yml",
               ".github/"
           ]
       }
   }
   

4. Trigger it by re-installing anything: composer install (or composer update). Patterns run per package as it is installed/extracted.

Where to look first: vendor/barryvdh/composer-cleanup-plugin/src/ for the CleanupPlugin class and the hard-coded default pattern list — that's the fastest way to know exactly what will be deleted before you trust it on a real project.

First use case: trimming vendor/ inside a Docker build or CI artifact. Laravel's own framework package ships its tests/ and docs, and so do PHPUnit, Mockery, and most first-party packages — dropping them is a meaningful, low-risk size win.

Implementation Patterns

Baseline configuration on every Laravel project. Add the plugin and extra.cleanup to composer.json for consistent vendor output across the team. Commit both together so CI and local installs behave identically.

Docker layer slimming. Run composer install --no-dev --prefer-dist --classmap-authoritative and let the plugin clean up in the same layer:

COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts --no-autoloader --prefer-dist
COPY . .
RUN composer dump-autoload --optimize

Cleanup happens during the install step, so it is baked into the layer and doesn't add runtime cost.

CI cache/artifact shrinking. If you cache vendor/ between jobs or upload it as a build artifact, cleanup keeps the cache small without touching composer.lock. It also makes vendor diffs less noisy when you inspect what changed after an update.

Selective aggressiveness. Keep a second, narrower extra.cleanup.ignore for environments where you might actually need vendor tooling — e.g. a QA image that runs package test suites. In practice this means two composer manifests or a small composer config extra.cleanup.ignore step in CI rather than one global list.

Combining with --no-dev. The plugin does not distinguish dev and prod packages — it applies to everything installed. If you're already running --no-dev, your remaining dev-package bloat is small; the plugin's value comes from stripping test/docs out of the production framework and library packages.

Pairing with an optimized autoloader. Order matters only in that you don't want dump-autoload --optimize to run before cleanup and produce a classmap referencing removed files. Restrict patterns to non-src/ paths and this is a non-issue.

Gotchas and Tips

• Package name vs. repository name. The repo is composer-cleanup-plugin but the package is published as composer-cleanup-login. composer require barryvdh/composer-cleanup-login is the correct command — don't guess from the GitHub URL.
• Forgetting allow-plugins. Without the config entry the plugin silently doesn't run and you'll spend time wondering why vendor/ is unchanged. Check composer diagnose / the install output for the plugin approval note.
• --no-scripts does not disable package events. Plugin subscribers respond to package install/update events, which are dispatched independently of script events. So composer install --no-scripts will still delete files — don't rely on it as an escape hatch.
• It only runs on install/update, never retroactively. An already-populated vendor/ won't be cleaned until packages are reinstalled. Use composer reinstall "vendor/*" or delete vendor/ and reinstall if you need to apply a new pattern set.
• path repositories are dangerous. For a "type": "path" repository, the "installed package" is your working copy (often symlinked). A cleanup pass will delete files from your own source tree. Exclude path-symlinked packages from the pattern set or don't use the plugin while developing a local package.
• Never pattern-match PHP source. Removing a class file that the generated classmap still references produces confusing Class not found errors that look like autoload bugs. Keep patterns confined to docs, tests, examples, and CI config.
• Rare runtime dependencies on test fixtures. A handful of packages read tests/ fixtures or example configs at runtime. If a package starts throwing "file not found" after an unrelated update, reinstall that package (composer reinstall vendor/package) and narrow the pattern set.
• Debugging what was removed. Run composer install -vvv — the plugin logs each file/directory it deletes. Cross-reference against the pattern list in src/CleanupPlugin.php if behavior surprises you.
• No extension points worth relying on. The plugin is intentionally tiny (one subscriber, one pattern list). If you need conditional cleanup — different rules for dev vs. prod, or per-package overrides — write a small custom Composer event subscriber or a post-install-cmd script rather than fighting the plugin's configuration.
• Composer cache is untouched. Dist archives in ~/.composer/cache still contain the full package, so composer install after a cache hit re-extracts and re-cleans. Nothing is permanently lost.