1
0
Fork 0

[docs] Change alias article according to comments

1.0.x-dev alias is safer than 1.0-dev. require-dev is also supported.
Clarify that inline aliases are for matching constraints of deps.
Tell users to avoid inline aliasing if possible.
pull/626/head
Igor Wiedler 2012-04-26 19:21:31 +02:00
parent 3b40771089
commit 6a1843da38
1 changed files with 19 additions and 11 deletions

View File

@ -24,13 +24,13 @@ Enter aliases.
The `dev-master` branch is one in your main VCS repo. It is rather common that The `dev-master` branch is one in your main VCS repo. It is rather common that
someone will want the latest master dev version. Thus, Composer allows you to someone will want the latest master dev version. Thus, Composer allows you to
alias your `dev-master` branch to a `1.0-dev` version. It is done by alias your `dev-master` branch to a `1.0.x-dev` version. It is done by
specifying a `branch-alias` field under `extra` in `composer.json`: specifying a `branch-alias` field under `extra` in `composer.json`:
{ {
"extra": { "extra": {
"branch-alias": { "branch-alias": {
"dev-master": "1.0-dev" "dev-master": "1.0.x-dev"
} }
} }
} }
@ -52,10 +52,13 @@ commit changes to version control.
This is not really fun when you just want to try a bugfix of some library that This is not really fun when you just want to try a bugfix of some library that
is a dependency of your local project. is a dependency of your local project.
For this reason, you can alias packages in your `require` field. Let's say you For this reason, you can alias packages in your `require` and `require-dev`
found a bug in the `monolog/monolog` package. You cloned Monolog on GitHub and fields. Let's say you found a bug in the `monolog/monolog` package. You cloned
fixed the issue in a branch named `bugfix`. Now you want to install that Monolog on GitHub and fixed the issue in a branch named `bugfix`. Now you want
version of monolog in your local project. to install that version of monolog in your local project.
You are using `symfony/monolog-bundle` which requires `monolog/monolog` version
`1.*`. So you need your `dev-bugfix` to match that constraint.
Just add this to your project's root `composer.json`: Just add this to your project's root `composer.json`:
@ -67,16 +70,21 @@ Just add this to your project's root `composer.json`:
} }
], ],
"require": { "require": {
"monolog/monolog": "dev-bugfix as 1.0-dev" "symfony/monolog-bundle": "2.0",
"monolog/monolog": "dev-bugfix as 1.0.x-dev"
} }
} }
That will fetch the `dev-bugfix` version of `monolog/monolog` from your GitHub That will fetch the `dev-bugfix` version of `monolog/monolog` from your GitHub
and alias it to `1.0-dev`. and alias it to `1.0.x-dev`.
> **Note:** If a package with inline aliases is required, the alias (right of > **Note:** If a package with inline aliases is required, the alias (right of
> the `as`) is used as the version constraint. The part left of the `as` is > the `as`) is used as the version constraint. The part left of the `as` is
> discarded. As a consequence, if A requires B and B requires `monolog/monolog` > discarded. As a consequence, if A requires B and B requires `monolog/monolog`
> version `dev-bugfix as 1.0-dev`, installing A will make B require `1.0-dev`, > version `dev-bugfix as 1.0.x-dev`, installing A will make B require
> which may exist as a branch alias or an actual `1.0` branch. If it does not, > `1.0.x-dev`, which may exist as a branch alias or an actual `1.0` branch. If
> it must be re-inline-aliased in A's `composer.json`. > it does not, it must be re-inline-aliased in A's `composer.json`.
> **Note:** Inline aliasing should be avoided, especially for published
> packages. If you found a bug, try and get your fix merged upstream. This
> helps to avoid issues for users of your package.