En el Manual de Composer ya hemos explicado todo el flujo de trabajo que te permitirá adoptar Composer en tu día a día en el desarrollo PHP. Realmente con lo que sabes y una rápida referencia en la documentación para consultar detalles que se nos hayan podido escapar, tienes todo lo que hace falta para usar Composer.

Sin embargo, hemos pasado muy "de puntillas" por la estructura del archivo composer.json que nos sirve para declarar las características de nuestro proyecto y las dependencias que pueda tener.

Pero Ojo, el composer.json nos sirve no solamente para que Composer sepa las dependencias que debe instalar para tu proyecto, también sirve en el caso que quieras liberar tu proyecto como un paquete para que lo usen otras personas y publicarlo en Packagist. En este artículo nos vamos a centrar más en lo que necesitas para definir tus dependencias.

El esquema composer.json

El schema (esquema) de un JSON define la estructura del documento así como los valores posibles que tengan cada uno de sus campos. La dirección concreta donde puedes encontrar la descripción completa del schema del composer.json la encuentras en esta URL de documentación:

https://getcomposer.org/doc/04-schema.md

Campos que describen tu proyecto

Veamos ahora una serie de campos para ofrecer información de nosotros como desarrolladores de un proyecto. Estos son los datos que necesitarías enviar a Packagist, pero que no son necesarios a nivel interno para que Composer funcione, sino más bien para etiquetar tu desarrollo, mencionar autores, etc.

name:
Sirve para indicar el nombre del autor, se compone de dos partes, el "vendor" (la empresa o nick del desarrollador o grupo que lo ha creado) y el nombre del proyecto propiamente dicho. Por supuesto, un vendor puede crear diversas librerías o paquetes y quedarían todas vinculadas al mismo vendor con nombres de proyectos distintos.

description:
Es la descripción que ofrecemos de este paquete. Es un texto normalmente de una única línea.

homepage:
Una URL del sitio web del proyecto.

authors:
Es un array con los autores del proyecto. Cada uno de los elementos de ese array es a su vez un objeto JSON donde se pueden indicar distintos datos: name, email, homepage, role (rol dentro del proyecto).

"authors": [
	{
		"name": "Miguel Angel Alvarez",
		"email": "algo@desarrolloweb.com",
		"homepage": "http://www.desarrolloweb.com",
		"role": "Project Manager"
	},
	{
		"name": "Alvaro Martínez",
		"email": "algo@escuela.it",
		"homepage": "http://www.escuela.it",
		"role": "Beta tester"
	}
]

Definir las dependencias

A nivel de desarrollo de nuestras propias aplicaciones, el campo más importante donde debemos centrarnos es en la definición de las dependencias, así como las versiones que deseamos que sean instaladas, o actualizadas de cada una de esas dependencias.

require:
Es un objeto con una serie de pares clave/valor que definen cada una de las dependencias que Composer debe instalar para nuestro proyecto. En la clave debemos de indicar el nombre del paquete que depende (que obtienes del sitio de Packagist) y como valor indicamos la versión que deseamos que esté instalada, o el rango de versiones.

"require": {
	"respect/validation": "0.6.*",
	"phpunit/phpunit": ">=4.0",
	"tinymce/tinymce": "dev-master"
}

En los pares clave/valor de cada una de las dependencias, la parte del nombre del vendor y la librería es muy fácil de obtener. Simplemente te vas a Packagist buscas y escoges el paquete que más te convenga y copias la cadena del nombre. Por ejemplo "respect/validation" indica que "respect" es el vendor y "validation" es el nombre de la librería.

La parte de la versión también te puedes ayudar de Packagist, pues ahí encontrarás la lista de versiones liberadas de esa librería y disponibles como paquetes. Lo que verás es que la expresión que define la versión tiene algunos caracteres "comodín" que debes aprender a tratar. En general puedes usar estas variantes de expresión.

• Versión exacta: indicas a Composer que debe instalar una versión exacta, y solo esa. Quiere decir que nunca te va a actualizar el paquete, porque tu proyecto debe tener esa versión y no otra. Por ejemplo "4.3.1".
  
  
• Rango de versiones: permite indicar versiones que sean mayor que una determinada, menor o que esté entre una versión y otra. Por ejemplo ">=2.0".
  
  
• Comodín: Permite decir cualquier versión de una release mayor. Bueno, puedes usar algo como "4.*" para indicar que se deje siempre la versión 4 y cualquier cosa. O algo más restrictivo como "4.2.*" que te pondrá siempre la versión 4.2.x. Lógicamente, en este caso cuando actualices, se colocará la versión más avanzada permitida por ese comodín.
  
  
• Virgulilla (el rabo de la eñe): permite indicar la versión de una manera diferente, "próxima versión significativa". Por ejemplo, "~2.2" siempre te dejará la versión mayor o igual a la 2.2 y menor que la 3.0. Por ejemplo "~2.2.1" te pondrá la versión mayor igual que 2.2.1 y menor que 2.3.
  
  
• También te permite cosas como "dev-master" que será la versión actual de desarrollo, que puede darse el caso que no sea estable. "1.0.*@beta" que te permitirá colocar versiones beta o "@dev" que también referencia a versiones de desarrollo que pueden sufrir inestabilidad.

Para encontrar otras posibilidades, por favor consulta la documentación de Composer, en estos enlaces:

• Crear los enlaces a paquetes dependientes
  
• Definir las versiones aceptadas

De momento eso es todo. Con la información que tienes estamos seguros que le podrás sacar todo el jugo a Composer para gestionar las dependencias de tus proyectos PHP.