Use lowercase w first. It updates the named package plus its dependencies, except packages you require directly in your own composer.json. Use uppercase W only when a root requirement must move too. Both keep the rest of the lock file alone, which keeps a security update small.
The two flags
The Composer documentation defines them. The with-dependencies option, short form lowercase w, updates also the dependencies of packages in the argument list, except those which are root requirements. The with-all-dependencies option, short form uppercase W, updates the dependencies of packages in the argument list, including those which are root requirements. Each can also be set through an environment variable.
A partial update, naming only one package, is the safest base. The docs explain that you can also supply a custom version constraint for the update, and that for packages also required in your composer.json the custom constraint must be a subset of the existing constraint. They add that composer.json is not modified by these temporary constraints.
Which one to pick
| Situation | Command shape | Reason |
|---|---|---|
| Fixed version is inside current constraints | Update the one package | Smallest change |
| The package needs a newer sub dependency | Update with lowercase w | Moves its dependencies only |
| A package you require directly blocks the fix | Update with uppercase W | Lets root requirements move |
| Fix needs a version outside your constraint | Edit composer.json, then update | The manifest must change |
Steps
- Use the prohibits command to see what blocks the fix (covered in the guide on why a PHP package will not upgrade).
- Run a partial update for the one package.
- If Composer reports it must change other packages, add lowercase w.
- Only if a root requirement is the blocker, add uppercase W.
- Review the composer.lock diff. Count the packages that changed.
- Run composer audit, then your tests.
composer update vendor/package
composer update vendor/package -w
composer update vendor/package -W
Why not update everything
A full update is tempting during a security push, but it moves every package to the newest version your constraints allow. Each moved package is a change you did not review. Keeping the update to the vulnerable package and its necessary dependencies gives you a lock file diff a reviewer can read in minutes.
If the diff comes back much bigger than you expected, stop and look. A large diff after naming one package usually means a shared dependency has a tight relationship with several others, and that is a signal to test more, not less.
After the update
Commit composer.lock with the change, and make CI install from the lock file, not from a fresh resolve. The goal is that the version you tested is the version that ships. Then rescan. A passing update command does not prove that the flagged version is gone from the resolved set.
Try it yourself
Click through it at your own pace, or open it full screen. Note how a fixed version is shown, then think about what else the update must move.
Where Safeguard fits
Safeguard scans dependencies, runs reachability analysis to show which findings your code can actually reach, and can open fix pull requests through autonomous remediation. That last feature is off by default and every category starts on Manual, so a person approves each change. You can try a free scan on a repository first.
Quick check
Does lowercase w update packages I require directly?
No. It updates dependencies except those that are root requirements. Uppercase W includes them.
Do temporary constraints change composer.json?
No. The documentation says composer.json is not modified by those temporary update constraints.
Sources
Last reviewed: 19 October 2026.
