Why use aliases?

The following column of composer tutorial will introduce to you the reasons for using branch aliases. I hope it will be helpful to friends in need!

Why use aliases?

When you use a version control system repository, you can only get a comparable version from branches that look like versions, such as 2.0 or 2.0.x. For the master branch, you only get one dev-master version. For the bugfix branch, you will get the dev-bugfix version.

If your master branch is used to mark the 1.0 development process, such as 1.0.1, 1.0.2, 1.0.3, etc., packages that depend on your library may need 1.0.*.

If someone wants to use the latest dev-master, they will encounter a problem: some packages may require 1.0.*, so these two will cause conflicts, because dev-master does not Matches 1.0.*.

Based on the above, aliases appear.

Branch Alias

The dev-master branch is one of the main VCS repositories. It's common that some people will want the latest major development version. Therefore, Composer allows you to alias the dev-master branch to the 1.0.x-dev version. It is done by specifying the branch-alias field under extra in composer.json:

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

If the alias is a non-comparable version (such as dev-develop), you must prefix the branch name with dev- . You can also add aliases (i.e. starting with a number and ending with .x-dev) for comparable versions, but only as more specific versions. For example, 1.x-dev can be aliased as 1.2.x-dev.

The alias must be a comparable development version, and branch-alias must appear on the branch it refers to. For dev-master you need to commit it on the master branch.

So a lot of people need 1.0.* now and he will be happy to install dev-master .

To use a branch alias, you must own the repository for the aliased package. If you want to add an alias to a third-party package without maintaining a fork of it, use inline aliases, as described below.

Requires inline aliases

Branch aliases are useful for major lines of development. But in order to use them, you need to control the source repository, and changes need to be committed to version control.

It's not very interesting when you want to try a bug fix for a library that is a dependency of your local project.

So you can alias packages in the require and require-dev fields. Suppose you find a bug in the monolog/monolog package. You clone Monolog on GitHub and fix the problem in a branch called bugfix. Now you want to install this version of monolog in your local project.

You are using symfony/monolog-bundle, which requires monolog/monolog version 1.*. Therefore, you need to use dev-bugfix to match this constraint.

Add this to your project's root composer.json:

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

This will get the version of monolog/monolog's dev-bugfix from your Github and alias it to 1.0.x -dev.

Note: Inline aliasing is a feature only available to the root user. If a package with an inline alias is required, use the alias (right side of as ) as a version constraint. The left part of as is discarded. So if A requires B and B requires the monolog/monolog version dev-bugfix for 1.0.x-dev , installing A will also make B require 1.0.x-dev as well, which may exist as a branch alias or the actual 1.0 branch. If not, you'll have to alias inline again in A 's composer.json .

Note: Using inline aliases should be avoided, especially for published packages/libraries. If you find a bug, try merging your fix upstream, this will help avoid problems for users of your package.

For more composer technical articles, please visit the composer command usage tutorial column!

The above is the detailed content of Why use aliases?. For more information, please follow other related articles on the PHP Chinese website!