How to Remove a Package in Laravel with Composer

By the end of this page, you will understand how Composer removes packages in a Laravel project, why manually editing composer.json is often not enough, and which Laravel-specific cleanup steps may also be required. You will also learn the correct commands, common mistakes, and how to verify that a package has actually been removed.

Composer is the dependency manager for PHP projects, including Laravel applications. Its job is to install, update, and remove packages listed in composer.json, then lock the exact installed versions in composer.lock.

When you want to remove a package, the most reliable approach is not to manually delete it from composer.json. Instead, you should use Composer's built-in remove command:

composer remove vendor/package

This matters because Composer does more than just edit one file:

• It removes the package from composer.json
• It updates composer.lock
• It removes the package from the vendor/ directory if no longer needed
• It regenerates autoload files

In Laravel, there may also be framework-specific integration points to clean up, such as:

• Service providers in config/app.php or older app.php setups
• Class aliases
• Published configuration files
• Views, migrations, or assets copied into your project
• Cached configuration or route files

If you only delete a line from composer.json, the package can still appear present because:

• It may still exist in composer.lock

Think of Composer as a warehouse manager.

• composer.json is the shopping list
• composer.lock is the exact receipt of what was actually bought
• vendor/ is the storage room containing the packages
• Laravel config and cache are like labels and notes taped around your app

If you only erase an item from the shopping list, that does not automatically clean the storage room or update the receipt. Using:

composer remove vendor/package

is like telling the warehouse manager to:

1. Remove the item from the list
2. Update the receipt
3. Take it out of storage
4. Re-label everything correctly

Then in Laravel, you may also need to remove the extra notes and labels, such as service providers, aliases, and cached config.

The standard syntax is:

composer remove vendor/package

Example

Suppose your Laravel app uses this package:

{
  "require": {
    "laravel/framework": "^10.0",
    "barryvdh/laravel-debugbar": "^3.9"
  }
}

To remove it, run:

composer remove barryvdh/laravel-debugbar

Composer will:

• Remove it from composer.json
• Update composer.lock
• Remove its files from vendor/
• Rebuild autoload files

Laravel cleanup example

If your project manually registered the package in config/app.php, you may also need to remove entries like these:

'providers' => [
    ::,
],

 => [
     => ::,
],

Consider this command:

composer remove vendor/package

Here is what happens step by step:

1. Composer reads your composer.json
2. It finds vendor/package in your dependencies
3. It removes that dependency entry
4. It recalculates the dependency graph
5. It updates composer.lock to match the new dependency set
6. It deletes package files from vendor/ if no remaining package needs them
7. It regenerates the autoloader

Small example

Imagine your composer.json contains:

{
  "require": {
    "laravel/framework": "^10.0",
    "vendor/package": "^1.0"
  }
}

You run:

composer remove vendor/package

After that:

Removing packages is common in real Laravel projects.

1. Replacing one package with another

You may uninstall a logging, image, payment, or admin package before switching to a new one.

2. Reducing app size and complexity

A package added during experimentation may no longer be needed in production.

3. Fixing dependency conflicts

A package may block upgrades to a newer Laravel or PHP version.

4. Removing development tools

You might remove debugging or profiling packages from a deployed application.

5. Security and maintenance cleanup

If a package is abandoned or vulnerable, it is often better to remove it entirely.

6. Simplifying deployment

Fewer dependencies usually mean faster installs, smaller vendor directories, and fewer integration points to maintain.

In real projects, developers usually remove packages in a few layers.

Typical pattern

1. Remove the package with Composer
2. Remove framework registration code
3. Remove package-specific config or published files
4. Clear caches
5. Run tests

Common Laravel patterns

Guard clause before cleanup

Teams often first verify whether the package is direct or transitive:

composer why vendor/package

If another package depends on it, you may not be able to remove it directly.

Configuration cleanup

Older Laravel apps may register providers and aliases manually. Newer apps often use package auto-discovery, so there may be less manual cleanup.

Cache clearing

After removing package classes, cached config may still point to them. That can trigger errors such as class not found.

Validation through tests

After removal, developers run:

php artisan test

or:

vendor/bin/phpunit

This confirms no remaining code depends on the removed package.

Published assets and migrations

Some packages copy files into your project. Composer removes package code from vendor/, but it does not automatically delete files already published into:

1. Editing composer.json manually instead of using composer remove

This is the most common issue.

Less reliable approach

{
  "require": {
    "laravel/framework": "^10.0"
  }
}

If you only delete the package line and do not let Composer manage the full removal process, your lock file and installed packages may become inconsistent.

Better approach

composer remove vendor/package

2. Forgetting Laravel service providers or aliases

Broken example:

'providers' => [
    Vendor\Package\ServiceProvider::class,
],

If the package is removed but this line stays, Laravel may fail during boot.

3. Forgetting cached configuration

A package may be gone, but Laravel still uses old cached config.

Fix:

php artisan optimize:clear

Manual edit vs Composer command

# Remove a package properly
composer remove vendor/package

# Check whether a package is still installed
composer show vendor/package

# See why a package exists in the project
composer why vendor/package

# Clear Laravel caches after removal
php artisan optimize:clear

Rules to remember

• Prefer composer remove over manual editing
• Remove Laravel service providers and aliases if manually registered
• Clear Laravel caches after removing package classes
• Check for published files in config/, public/, resources/, and database/
• Search your codebase for leftover references
• Use composer why if the package seems impossible to remove

Common edge cases

• The package is still required by another package
• The package used Laravel auto-discovery, so there may be no provider to remove manually
• Config cache may still reference deleted classes
• Published files remain even after the package is removed

How do I uninstall a Laravel package correctly?

Use:

composer remove vendor/package

Then remove Laravel-specific references such as service providers, aliases, and published files if needed.

Why is deleting the package from composer.json not enough?

Because Composer also tracks dependencies in composer.lock and the vendor/ directory. Manual deletion does not fully synchronize everything.

Do I need to run composer dump-autoload after composer remove?

Usually no. composer remove already regenerates autoload files.

Why does Laravel still try to load the removed package?

Most often because of cached config, a remaining service provider, an alias, or leftover code references.

How can I check whether another package still depends on it?

Run:

composer why vendor/package

Does Composer delete published config files and migrations?

No. Files copied into your Laravel project usually need to be removed manually.

What command should I run after removing a package in Laravel?

A good default is:

• Composer require — the opposite operation of adding a package correctly
• composer.lock — explains why installed dependencies may not match manual edits alone
• Autoloading in PHP — helps explain why class references may still appear until autoload is rebuilt
• Laravel service providers — many packages register bootstrapping logic through providers
• Laravel facades and aliases — packages often expose shortcuts that must be removed
• Laravel package auto-discovery — important for understanding why some packages need less manual cleanup
• Laravel cache clearing — useful when removed package classes are still referenced from cached config
• Dependency graph — explains why one package may remain because another package still requires it