Composer

Two files tell the story: composer.json lists what you want with version constraints, and composer.lock records exactly what was installed with hashes. composer install reproduces the lock; composer update changes it. The vendor/ folder holds the installed code, which you normally do not commit.

composer outdated shows which packages have newer versions, and composer audit checks the lock against a database of known security advisories. For plugins, the WPackagist mirror turns WordPress.org slugs into Composer package names such as wpackagist-plugin/wordfence.

A developer pulls a WooCommerce site to a laptop and runs composer install. It installs WooCommerce 9.1.2 and a pinned payments gateway at 3.4.0 exactly as production has. A teammate who ran composer update the day before is on gateway 3.5.0 and sees a checkout field that does not exist on the live site.

The team agrees only the lock file changes through pull requests. The bug stops appearing because both machines now read the same composer.lock.

Composer is the tool and Bedrock is one opinionated way to lay out a WordPress project so Composer can manage it. You can use Composer for a single plugin's own libraries without moving core. Composer does not install premium plugins that have no repository, and it does not run WordPress database upgrades.

Running composer update on production. Committing vendor/ in one place and ignoring it in another. Using a loose constraint like * and getting a breaking major version. Forgetting that two plugins can bundle different copies of the same library and collide in one namespace. Leaving composer.lock out of version control.

If you ship a plugin or custom theme with PHP libraries, add composer.json and namespace them with a prefix tool so they cannot clash with another plugin. For a whole site, try composer outdated on a staging copy and see how many of your plugins have a Composer source before committing to the workflow.