How to Remove an Installed Composer Package From a Laravel Project

Removing a Composer package cleanly from a Laravel project is mostly just composer remove, but a package often leaves behind published config files, a manually-registered service provider, or other artifacts that aren't automatically cleaned up — checking for these afterward is what actually makes the removal complete.

The basic removal command

composer remove vendor/package-name

This removes the package from composer.json, deletes it from vendor/, and updates composer.lock — all in one command.

Checking for a published config file left behind

ls config/ | grep package-name

Many packages publish their own config file into your project's config/ directory during installation (via php artisan vendor:publish) — composer remove doesn't touch this published file at all, since it's now considered part of your own project, not the package's files; deleting it manually is a separate, deliberate step if it's genuinely no longer needed.

Removing a manually registered service provider (pre-package-discovery, or manually added)

// config/app.php — remove this line if present
'providers' => [
    // ...
    Vendor\PackageName\PackageServiceProvider::class, // remove this
],

Modern packages generally use Laravel's package auto-discovery and don't need manual registration in config/app.php at all — but for an older package, or one explicitly opted out of auto-discovery, a manually added provider entry needs to be removed by hand, since Composer has no way to know it was ever added there in the first place.

Checking for published migrations, views, or assets

find database/migrations -name "*package_name*"
find resources/views/vendor -type d -name "package-name"
find public/vendor -type d -name "package-name"

A package that published migrations, views, or public assets into your project leaves those files behind after removal — whether to delete them depends on whether they're still needed (a migration that's already run and created real database structure you still want to keep, for instance, generally should stay even after removing the package that originally shipped it).

Clearing cached configuration after removal

php artisan config:clear
php artisan cache:clear
composer dump-autoload

If configuration was ever cached (php artisan config:cache), a removed package's now-stale config reference can cause errors until the cache is cleared — running these clear commands after any package removal is a reasonable habit to avoid a confusing "class not found" error referencing a package that was just intentionally removed.

Verifying the application still works after removal

Running the application's test suite, or at minimum manually checking any feature that relied on the removed package, confirms nothing was silently depending on it in a way that wasn't obvious from just reading through the codebase for explicit references.