Programster's Blog

Tutorials focusing on Linux, programming, and open-source

Composer Aliases

Quite often, you will have PHP packages that depend upon other packages. For example, I have a private internal SDK that extends the functionality of the public SDK which everyone can use. This means that whenever I create projects, I just add a line to include the internal sdk and the public one gets used automatically, like so:

{
    "repositories": [ { "type": "composer", "url": "https://satis.myPrivateDomain.com/" } ],
    "require": {
        "programster/internal-api-sdk" : "0.2.*"
    }
}

This will automatically pull down and use the latest version of programster/api-sdk that is specified as a requirement in the internal-api-sdk because it uses a wildcard like this: 0.3.*.

The Problem

If I need to develop and test a change to the public sdk (dependency), and I were to just manually add the dev branch to the composer file like so:

{
    "repositories": [ { "type": "composer", "url": "https://satis.myPrivateDomain.com/" } ],
    "require": {
        "programster/api-sdk": "dev-my_branch",
        "programster/internal-api-sdk" : "0.2.*"
    }
}

... then I would get a bunch of error messages from composer like so:

  Problem 1
    - programster/internal-api-sdk 0.2.6 requires programster/api-sdk 0.3.* -> satisfiable by programster/api-sdk[0.3.0, 0.3.1, 0.3.10, 0.3.11, 0.3.12, 0.3.13, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9] but these conflict with your requirements or minimum-stability.
    - programster/internal-api-sdk 0.2.5 requires programster/api-sdk 0.3.* -> satisfiable by programster/api-sdk[0.3.0, 0.3.1, 0.3.10, 0.3.11, 0.3.12, 0.3.13, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9] but these conflict with your requirements or minimum-stability.
    - programster/internal-api-sdk 0.2.4 requires programster/api-sdk 0.3.* -> satisfiable by programster/api-sdk[0.3.0, 0.3.1, 0.3.10, 0.3.11, 0.3.12, 0.3.13, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9] but these conflict with your requirements or minimum-stability.
    - programster/internal-api-sdk 0.2.3 requires programster/api-sdk 0.3.* -> satisfiable by programster/api-sdk[0.3.0, 0.3.1, 0.3.10, 0.3.11, 0.3.12, 0.3.13, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9] but these conflict with your requirements or minimum-stability.
    - programster/internal-api-sdk 0.2.2 requires programster/api-sdk 0.3.* -> satisfiable by programster/api-sdk[0.3.0, 0.3.1, 0.3.10, 0.3.11, 0.3.12, 0.3.13, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9] but these conflict with your requirements or minimum-stability.
    - programster/internal-api-sdk 0.2.1 requires programster/api-sdk 0.3.* -> satisfiable by programster/api-sdk[0.3.0, 0.3.1, 0.3.10, 0.3.11, 0.3.12, 0.3.13, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9] but these conflict with your requirements or minimum-stability.
    - programster/internal-api-sdk 0.2.0 requires programster/api-sdk 0.3.* -> satisfiable by programster/api-sdk[0.3.0, 0.3.1, 0.3.10, 0.3.11, 0.3.12, 0.3.13, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9] but these conflict with your requirements or minimum-stability.
    - programster/internal-api-sdk 0.2.6 requires programster/api-sdk 0.3.* -> satisfiable by programster/api-sdk[0.3.0, 0.3.1, 0.3.10, 0.3.11, 0.3.12, 0.3.13, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9] but these conflict with your requirements or minimum-stability.
    - Installation request for programster/internal-api-sdk 0.2.* -> satisfiable by programster/internal-api-sdk[0.2.6, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5].

I could temporarily update the internal sdk to require the dev package, or temporarily tag and push the dev package as the latest version number, but both of these workarounds are long-winded and dangerous!

The Solution - Using An Alias

It is much easier to just use an alias in my test project to specify that the dev version of package is the release version that it will become when I have finished testing. This is done like so:

{
    "repositories": [ { "type": "composer", "url": "https://satis.myPrivateDomain.com/" } ],
    "require": {
        "programster/api-sdk": "dev-my_branch as 0.3.10",
        "programster/internal-api-sdk" : "0.2.*"
    }
}

Now I can run a composer update and it will use my dev branch so that I can continue with testing before officially pushing it as that alias version. Nobody else will accidentally use my dev branch as a release version and get annoyed when things start falling over. Just make sure you are doing this testing and change to the composer file in a branch nobody else is using.

References

Last updated: 28th February 2022
First published: 16th August 2018