¿Por qué se necesitan los alias?
Cuando guardas el código de tus paquetes en un repositorio de código VCS (es decir, Git, Mercurial o Subversion) Composer define automáticamente versiones para cualquier rama cuyo nombre parezca una versión (por ejemplo, la rama 2.0). Para el resto de ramas, Composer crea versiones prefijando su nombre ocn dev-. Así, la rama master se convierte en la versión dev-master, la rama bugfix corresponde a la versión dev-bugfix, etc.
Si utilizas la rama master para crear las etiquetas de la versión 1.0 de tu paquete (1.0.1, 1.0.2, 1.0.3, etc.), seguramente los proyectos externos dependerán de la versión 1.0.* de tu paquete.
Si ahora alguien quiere depender de la última versión de dev-master, entonces tiene un problema: otros paquetes requerirán la versión 1.0.* y se producirán conflictos, ya que dev-master no coincide con la versión 1.0.* (aunque en realidad, internamente son la misma versión).
Definiendo el alias de una rama
La rama master es probablemente la rama principal de tu repositorio de código. Al probar un proyecto, es común que los programadores quieran utilizar la versión más reciente de esa rama, que sería la versión dev-master. Por eso Composer te permite crear el alias 1.0.x-dev para la rama dev-master. Para ello, añade la opción branch-alias bajo la opción extra del archivo composer.json:
{
"extra": {
"branch-alias": {
"dev-master": "1.0.x-dev"
}
}
}La versión de la rama debe empezar siempre por dev- (es decir, debe ser una rama con un nombre que no se parezca a una versión) y el alias puedes elegirlo libremente, pero debe tener el formato de una versión y acabar en -dev. Esta propiedad branch-alias debe estar en el archivo composer.json de la rama a la que está referenciando (en este caso, en la rama master).
Con la configuración anterior, los programadores ya pueden indicar 1.0.* como versión del paquete y en realidad, estarán instalando la versión dev-master.
Para definir alias en una rama, debes ser el responsable del repositorio donde se encuentra el paquete. Si quieres crear alias para paquetes de terceros y no tener que hacer un fork, debes utilizar los "alias temporales" o inline aliases.
Definiendo un alias temporal
Los alias de las ramas explicados en la sección anterior son muy útiles para las líneas principales de desarrollo de los paquetes. El problema es que para definir esos alias debes ser el responsable del repositorio y debes poder hacer commits a ese repositorio.
Este proceso completo es tedioso si lo único que quieres hacer es corregir un error de alguna librería de la que depende tu proyecto. Por eso Composer te permite crear alias directamente en las propiedades require y require-dev del archivo composer.json.
Imagina que has descubierto un error en el paquete monolog/monolog. Para solucionarlo, has clonado el proyecto Monolog en tu propio repositorio y has corregido el fallo en una rama llamada bugfix. El último paso consiste en utilizar esta versión de la librería en vez de la versión oficial del proyecto.
Supongamos también que utilizas el paquete symfony/monolog-bundle que a su vez depende de la versión 1.* del paquete monolog/monolog. El único cambio que debes hacer es añadir un alias en el paquete monolog/monolog para hacer creer a los demás paquetes que tu versión dev-bugfix es en realidad la versión 1.* que ellos esperan. Para ello, añade lo siguiente en tu archivo 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"
}
}Con esta configuración, Composer descargará e instalará tu versión dev-bugfix cada vez que un paquete requiera la versión 1.0.x-dev del paquete monolog/monolog.
Si dependes de un paquete que define este tipo de alias, la versión que se utiliza es la indicada en ese alias (lo que esté a la derecha de la palabra as). Por tanto, si el paquete A requiere el paquete B y este paquete B requiere la versión dev-bugfix as 1.0.x-dev de monolog/monolog, al instalar el paquete A se utilizará la versión 1.0.x-dev del paquete. Si no existe, tendrás que crear un nuevo alias en el archivo composer.json del paquete A.
Este tipo de alias deben ser evitados a toda costa, sobre todo en los paquetes pensados para distribuirlos públicamente. Si encuentras un error en una librería, notifícalo a sus autores y trata de que acepten tu pull request con la corrección del error.