Composer uses an alias

Alias

Why use an alias?

When you use the VCS repository, you will only get a version number like this: get it from the label published by the 2.0 2.0.x W hat's special is that for master branch, you'll get a newly committed dev-master version. F or your bugfix you'll get a newly submitted dev-bugfix And so on, these special version identities can be used to get the latest branch source code.

If your master publishes 1.0 version 1.0.1 1.0.2 1.0.3 any resource pack that depends on it may use 1.0.*

If someone dev-master they will run into a problem: other packages that depend on it may use this version 1.0.* , so there will be a conflict when you need this development version because dev-master does not meet the constraints of 1.0.* .

At this point, you can use an alias.

Branch alias

dev-master to a main branch on your VCS project. I t is fairly common for some users to want to use the latest development version. T herefore, Composer allows you to dev-master version 1.0.x-dev This is done by specifying the branch-alias field under extra in the composer.json file: extra

{
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

The branch version here must start dev- inconso before the version name), and the corresponding alias must be a comparable development version name (that is, start with a number .x-dev branch-alias must exist. For dev-master need to master it on the master branch.

As a result, anyone can get the dev-master version using the 1.0.* dev-master

In order to define a branch alias, you must be the owner of the package that requires the alias. If you want an alias for a third-party package and don't want to fork it into your own repository, you can use an in-line alias, which we'll mention next.

Use in-line alias

Branch aliasses are ideal for the main development branch. But in order to use them, you need to have control over the source code, and you need to submit alias modifications to the repository that you control.

This is not the best approach when you only want to try some package-dependent bug fixes in your local project.

For this reason, you can require the package you need in the require and require-dev fields. F or example, you monolog/monolog Y ou cloned Monolog on GitHub and fixed a problem on a branch called bugfix Now you want to install this version into your local project.

symfony/monolog-bundle require monolog/monolog and constrain 1.* . . So you need to get dev-bugfix meet that version constraint.

Just add the following to the composer.json the root of your project:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/you/monolog"
        }
    ],
    "require": {
        "symfony/monolog-bundle": "2.0",
        "monolog/monolog": "dev-bugfix as 1.0.x-dev"
    }
}

It will get the dev-bugfix version of monolog/monolog on your GitHub and 1.0.x-dev

Note: If you want to use an in-line alias for a resource pack, the as of as) must be able to use version constraints. as part of as will be discarded after this. T herefore, if A depends on B and B relies on monolog/monolog and the version constraint is dev-bugfix as 1.0.x-dev then the version constraint of B is used when installing A 1.0.x-dev at which point a "branch alias" or "1.0 series branch" must be present. Otherwise, the in-line composer.json again in the composer.json file of A.

Note: You should try to avoid in-line aliases, especially for packages that have already been published. I f you find a bug, try merging your fixes into the upstream branch. This will avoid problems with users using your resource pack.