Using Composer Path Repositories to Test Dependency Updates in Drupal Modules

The problem arises because Composer resolves dependencies using the metadata published to Packagist or Drupal.org, even when a module is installed locally. As a result, modifying a module’s composer.json in place does not affect dependency resolution unless Composer is explicitly told to treat that local copy as the authoritative source.

Shindelar’s example centres on the drupal/mcp_server module, which depends on the mcp/sdk package. When testing compatibility with a newer SDK release outside the declared version constraint, Composer blocks the update. The article shows how adding a "type": "path" repository to the project’s root composer.json redirects Composer to a locally cloned version of the module instead.

With the path repository in place, the module can be removed, cloned from its Git repository, and re-required in development mode. Composer then resolves dependencies using the local module’s metadata, allowing developers to update version constraints and test against newer libraries without altering upstream package definitions.

The approach is intended for development and testing workflows, particularly when iterating on contrib modules that rely on third-party SDKs. It does not bypass the need to update constraints and submit changes upstream, but it provides a controlled environment for validating those changes before doing so.