Remove a package using composer (without updating other packages)
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
Safely Removing Composer Packages: How to Use composer remove Without Updating Dependencies
As senior developers working with PHP ecosystems, we constantly deal with managing project dependencies. One of the most common tasks is removing unused or unwanted packages. However, a frequent pitfall arises when developers mistakenly use composer update, which triggers dependency resolution across the entire project, potentially introducing unintended changes to other packages you wish to leave untouched.
This guide will walk you through the correct, safe, and precise method for removing a specific package, like "watson/sitemap", without affecting your existing set of other dependencies.
The Danger of composer update vs. composer remove
Before diving into the solution, it is crucial to understand the difference between these two commands:
composer update: This command reads yourcomposer.jsonfile and attempts to resolve all listed dependencies against the latest available versions defined by semantic versioning constraints. If another package has a dependency that conflicts with this update, Composer will attempt to resolve those conflicts by updating or downgrading other packages in your project. This is powerful but risky if you only intend to modify one item.composer remove: This command specifically focuses on removing the target package and its associated files from yourvendordirectory, as well as updating thecomposer.jsonand the criticalcomposer.lockfile to reflect the removal. Crucially, it isolates the change to the specified package rather than recursively updating the entire dependency tree.
The Correct Method: Using composer remove
To safely uninstall a single package without triggering a full dependency resolution sweep, you should exclusively use the composer remove command.
For your specific scenario—removing "watson/sitemap"—the process is straightforward and highly contained:
Step 1: Execute the Removal Command
Navigate to your project root directory in the terminal and run the following command:
composer remove watson/sitemap
What Happens Under the Hood?
When you execute this command, Composer performs the following actions:
- Removes Files: It deletes the package directory from your
vendorfolder. - Updates Configuration: It modifies your
composer.jsonfile by removing"watson/sitemap"from therequireorrequire-devsections, depending on where it was declared. - Updates the Lock File: Most importantly, it updates the
composer.lockfile to reflect the new state of the dependency tree after the removal has been applied.
Because you are only targeting one package for deletion, Composer minimizes its scope of work. It does not initiate a full search and re-evaluation of all transitive dependencies in the way composer update does, keeping your other packages stable. This principle of careful dependency management is vital when building robust applications, much like understanding the structure behind frameworks like Laravel, where dependency resolution is key to stability (as discussed on laravelcompany.com).
Best Practices for Dependency Management
When managing dependencies, always prioritize specificity over generality. If your goal is simply to eliminate one package, use the tool designed specifically for that task (composer remove). Reserve composer update for intentional dependency upgrades or when you are actively managing version constraints across multiple packages.
If you ever need to inspect exactly how a package is linked within your project before removal, you can use composer why-not <package-name>, which helps illustrate the dependency graph without forcing an unnecessary update cycle.
Conclusion
Removing packages safely requires understanding the intent behind each Composer command. By choosing composer remove over composer update, you maintain granular control over your project's dependencies, ensuring that you can surgically remove unwanted code while preserving the integrity and stability of the rest of your application. This practice ensures cleaner dependency management, which is a cornerstone of writing scalable and maintainable PHP applications.