How to Remove a Package in Laravel via Composer: A Step-by-Step Guide

Introduction: Why "Junk" in a Project is Evil, and How Composer Helps Clean It Up

Have you ever noticed how a Laravel project gradually turns into a giant warehouse of unnecessary packages? You installed one package for a prototype, another for an experiment, and a third just "in case." Then the project lives and grows, while these packages hang around as dead weight, bloating the vendor folder and slowing down composer install.

Sooner or later, every developer asks themselves: "How can I remove a package from Laravel using PHP Composer?". And this is not just a technical operation—it's the art of tidying up. Today, we'll break down this process from A to Z: not just commands, but a complete cleanup cycle with examples, tips, and an analysis of typical pitfalls.

Ready to turn your project from a "dependency dump" into a streamlined system? Let's go!

What You Need to Know Before Removing a Package

Before running composer remove, let's understand how Composer manages dependencies in general. In Laravel (and any PHP project), Composer works through two main files:

\n
• composer.json — a list of all required packages and their versions.
\n
• composer.lock — an exact snapshot of installed versions to ensure the project works identically on all machines.
\n

When you remove a package, Composer updates both files: it removes the entry from composer.json and recalculates composer.lock without the removed dependency. But there's a catch: if the package is used by other packages, Composer will refuse to remove it. A smart tool, no doubt.

The Main Command: composer remove

The simplest and most correct way to remove a package is to use the built-in composer remove command. The syntax is extremely simple:

composer remove vendor/package-name

For example, if you want to remove the popular debugging package barryvdh/laravel-debugbar, the command would look like this:

composer remove barryvdh/laravel-debugbar

After execution, you'll see output similar to this:

Package "barryvdh/laravel-debugbar" removed from require\nLoading composer repositories with package information\nUpdating dependencies (including require-dev)\nNothing to install or update\nGenerating optimized autoload files\n

That's it! The package has disappeared from vendor, composer.json, and composer.lock. But this is just the beginning. The real magic happens when you start cleaning up the project from "leftovers."

Removing Dev Dependencies

If the package was installed only for development (e.g., phpunit/phpunit), it is usually listed in the require-dev section. Composer itself knows where to remove it from, but to be sure, you can specify the --dev flag:

composer remove --dev phpunit/phpunit

This ensures the command applies specifically to dev dependencies. Although in practice, Composer handles it perfectly even without the flag.

Manual Removal: When Automation is Powerless

There are situations when composer remove refuses to work. For example, if the package is a dependency of another package that you are not removing. Or if you accidentally deleted an entry from composer.json manually, but the package remains in vendor.

In such cases, you have to take drastic measures. Here is the algorithm for manual removal:

\n
1. Delete the package entry from the require or require-dev section of the composer.json file.
\n
2. Delete the package folder from vendor/vendor/package-name (you can simply delete the entire vendor folder—but that's radical).
\n
3. Run composer updat
\n