Sometimes, you need to work on a new version of a PHP package while testing it as part of another project. Perhaps you’ve created a new feature branch and it requires integration into a large code base to ensure it will meet all the requirements, or tests within that project will pass with the updates. While you can certainly release new “beta” versions as part of your workflow, that may not always be practical. Sometimes, you need a faster, less formal approach. Locally, you may might even use a symlink from your larger project’s vendor directory to the in-progress updates to your package. But how can your team easily use the latest code without resorting to hacks, or waiting for a formal release?

Thankfully, Composer has a handy feature that gives you a simple solution for this: Inline Branch Aliases.

Suppose you have a dependency within your code for at least version 1.2.0 of your package. This would likely look something like this within your composer.json file:

...
"require": {
    "your-namespace/my-package": "^1.2.0",
    ...
}

Perhaps the next version of your package will be 1.3.0, but you are not quite ready to release it yet. Making changes to the requirements to try to use the feature branch and removing the minimum versions could result in dependency conflicts, especially in larger projects where many dependencies need to be resolved. However, our developers who need to use the feature branch can simply do the following, creating an inline branch alias for their local use:

...
"require": {
    "your-namespace/the-package": "my-feature-branch as ^1.2.99",
    ...
}

This tells Composer to use the code in the branch named “my-feature-branch” as-if it was tagged as version 1.2.99. Of course, you can set whatever version is appropriate to your needs to resolve all constraints. I only suggest using the patch level of “99” on the current version to ensure Composer will treat your feature branch as the latest, but not continue to use it once you finally do release that next minor release (i.e. 1.3.0). Normally you would obviously not want to commit such temporary changes into your code base.

This approach works for fix branches or any other branches. It even will work on the master or main branch if necessary, although you’d need to list this as follows for Composer:

...
"require": {
    "your-namespace/the-package": "dev-master as ^1.2.99",
    ...
}