2.2. Preparando el archivo composer.json del proyecto

Lo único que necesitas para empezar a utilizar Composer en tu proyecto es crear un archivo llamado composer.json. En este archivo se describen las dependencias del proyecto y también puede contener otro tipo de información.

El archivo utiliza el formato JSON y es muy fácil tanto de leer como de escribir. El contenido del archivo normalmente consiste en una serie de estructuras de información anidadas.

2.2.1. La clave require

Lo primero (y a menudo lo único) que debes añadir en el archivo composer.json es una clave llamada require. De esta forma dices a Composer cuáles son los paquetes de los que depende tu proyecto.

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

El valor de require es un objeto que mapea nombres de paquetes (en este caso, monolog/monolog) con versiones de paquetes (en este caso, 1.0.*).

2.2.2. Nombres de paquetes

El nombre de cada paquete está formado por dos partes. La primera indica quién es su "vendor" o creador (una persona o una empresa) y la segunda indica el nombre del proyecto. A menudo las dos partes son idénticas, pero el nombre del creador es importante para evitar colisiones entre proyectos con el mismo nombre. Así es posible por ejemplo que dos personas diferentes creen un proyecto llamado json, de forma que sus paquetes podrían llamarse igorw/json y seldaek/json.

En este ejemplo se está requiriendo el paquete monolog/monolog, así que el nombre del creador es el mismo que el del proyecto. Esta es la práctica recomendada para aquellos proyectos que sean únicos. De esta forma, si esos proyectos en el futuro lanzan otros proyectos, el mismo nombre del creador se podrá utilizar en todos ellos.

Si desarrollas una librería, esta técnica también te permitirá dividir el proyecto en varias partes más pequeñas y desacopladas, manteniendo todas ellas bajo el mismo creador.

2.2.3. Versiones de paquetes

En el ejemplo anterior, la versión requerida de la librería es 1.0.*, lo que significa que se puede utilizar cualquier versión de la rama 1.0 (como por ejemplo 1.0.0, 1.0.2 o 1.0.20). Esta versión es equivalente a >=1.0 <1.1.

Las versiones requeridas se pueden especificar de muchas maneras diferentes, lo que da una gran versatilidad a Composer:

• Versión exacta: indica exactamente la versión específica que requieres, como por ejemplo 1.0.2.
• Rango de versiones: que se indican mediante los siguientes operadores de comparación: >, >=, <, <=, !=. Así podrías indicar la versión requerida como >=1.0 o combinar varios rangos separándolos por comas: >=1.0,<2.0.
• Comodines: indican la versión requerida con un comodín (*) mediante un patrón similar al de las expresiones regulares. La versión 1.0.* por ejemplo es equivalente a >=1.0,<1.1.
• La siguiente versión significativa: que se indica mediante el operador ~ y se interprea de la siguiente manera: ~1.2 es equivalente a >=1.2,<2.0, mientras que ~1.2.3 es equivalente a >=1.2.3,<1.3.

La última forma de indicar las versiones es sobre todo útil para aquellos proyectos que siguen el versionado semántico. Normalmente se utiliza para indicar la mínima versión que requieres de una librería, como por ejemplo ~1.2, que permite cualquier versión hasta la 2.0 (sin incluir la 2.0). Como en teoría no deberían producirse problemas de retrocompatibilidad hasta la versión 2.0, esta técnica debería funcionar bien para los proyectos buenos que cumplen las normas.

Otra forma de entender el operador ~ es que simplemente especifica la versión mínima requerida pero permite que el último dígito crezca tanto como quiera.

Composer por defecto sólo tiene en consideración las versiones estables de cada paquete. Si en tu proyecto necesitas versiones Release Candidate, beta, alpha o dev, tienes que usar las opciones de estabilidad. Si en vez de una versión inestable de un paquete necesitas las de todos los paquetes del proyecto, puedes utilizar la opción minimum-stability.