Uso Avanzado de Composer – Using Zend Framework 3

Translation into this language is not yet finished. You can help this project by translating the chapters and contributing your changes.

2.12. Uso Avanzado de Composer

Al principio de este capítulo hemos usado Composer para instalar el código de la biblioteca Zend Framework 3. Ahora vamos a describir rápidamente algunos usos avanzados de Composer.

Como ya sabemos, la única llave que es obligatoria en el archivo composer.json es require. Esta llave le dice a Composer que paquetes necesita la aplicación:

{
    "require": {
        "php": "^5.6 || ^7.0",
        "zendframework/zend-component-installer": "^1.0 || ^0.3 || ^1.0.0-dev@dev",
        "zendframework/zend-mvc": "^3.0.1",
        "zfcampus/zf-development-mode": "^3.0",
        "zendframework/zend-mvc-form": "^1.0",
        "zendframework/zend-mvc-plugins": "^1.0.1",
        "zendframework/zend-session": "^2.7.1"
    }
}

2.12.1. Nombre de los Paquetes y Versiones

El nombre de un paquete consiste en dos partes: el nombre del proveedor y el nombre del proyecto. Por ejemplo, el nombre del paquete «zendframework/zend-mvc» consiste en el nombre del proveedor «zendframework» y el nombre del proyecto «zend-mvc». Podemos buscar cada uno de los paquetes del proveedor «zendframework» en el sitio web Packagist.org (ver un ejemplo en la figura 2.8).

Figure 2.8. Podemos buscar paquetes en Packagist.org

Además, un paquete tiene un número de version asociado. Un número de versión consiste de un número principal, un número secundario, opcionalmente el número de compilación y opcionalmente un sufijo de estabilidad (ejemplo, b1, rc1). Dentro de la llave require especificamos la versión del paquete que es aceptable. Por ejemplo, «^5.6» significa que podemos instalar versiones superiores a «5.6» pero inferiores a «6.0» (es decir que podemos instalar solo aquellos paquetes que no rompen la retrocompatibilidad). En la tabla 2.2 se muestran las posibles maneras de especificar versiones aceptables:

Tabla 2.2. Definiciones de las Versiones de los Paquetes

Ejemplo de Definición	Descripción
3.0.1	Versión exacta. En este ejemplo solo la versión 3.0.1 se puede instalar.
>=3.0.1	La versión mayor o igual se puede instalar (3.0.1, 3.2.1, etc.)
>3.0.1	La versión mayor se puede instalar (3.0.2 etc.)
<=3.0.1	La versión menor o igual se puede instalar (1.0, 1.5, 2.0.0 etc.)
<3.0.1	La versión menor se puede instalar (1.0, 1.1, 1.9, etc.)
!=3.0.1	Todas las versiones con excepción de esta se pueden instalar.
>=3.0,<3.1.0	Cualquier versión dentro del rango de versiones se puede instalar.
3.*	Cualquier versión que tenga el número principal igual a 3 se puede instalar (el número secundario puede ser cualquiera).
~3.0	Cualquier versión que comience en 3.0 pero menor que el número de versión principal siguiente (equivalente a >=3.0,<4.0).
^3.0	Cualquier versión comenzando por 3.0 pero menor que la siguiente versión principal (equivalente a >=4.0,<4.0). Similar a `~3.0`, pero está más cercano al versionado semántico y siempre permite actualizaciones sin interrumpirlas.

2.12.2. Instalar y Actualizar Paquetes

Hemos visto como usar el comando php composer.phar install para instalar nuestras dependencias. Tan pronto como ejecutamos este comando Composer encuentra, descarga e instala las dependencias en nuestra carpeta vendor.

¿Es seguro instalar dependencias con Composer?

Algunas personas podrían tener miedo de administrar las dependencias usando Composer porque piensan que alguien puede actualizar por error o intencionalmente las dependencias de todo el sistema operativo causando que la aplicación falle. Observemos que Composer nunca instala dependencias para todo el sistema operativo en realidad Composer las instala en la carpeta APP_DIR/vendor/.

Después de la instalación Composer crea el archivo APP_DIR/composer.lock. Este archivo contiene todas las versiones de los paquetes que fueron instalados. Si ejecutamos el comando install de nuevo, Composer encontrará el archivo composer.lock, revisará que dependencias ya están instaladas y si todos los paquetes ya están instalados Composer no hará nada.

Ahora si suponemos que pasado un período de tiempo se publican nuevas actualizaciones de seguridad para nuestros paquetes vamos a querer actualizarlos para mantener la seguridad del sitio web, entonces, tenemos que escribir el siguiente comando:

php composer.phar update

Si queremos actualizar solo una dependencia escribimos su nombre de la siguiente manera:

php composer.phar update zendframework/zend-mvc

Después de ejecutar el comando update el archivo composer.lock también se actualizará.

¿Que hago si quiero regresar a la versión anterior del paquete?

Si el proceso de actualización trajo problemas inesperados a nuestros sistema podemos revertir los cambios en el archivo composer.lock y ejecutar el comando install de nuevo. Revertir los cambios del archivo composer.lock es muy fácil si usamos un sistema de control de versiones, como GIT o SVN. Si no usamos un sistema de control de versiones podemos hacer un respaldo del composer.lock antes de actualizar.

2.12.3. Agregar una Dependencia Nueva

Si queremos agregar una nueva dependencia a la aplicación podemos o editar el archivo composer.json manualmente o ejecutar un comando require. Por ejemplo, para instalar el módulo Doctrine ORM en nuestro sitio web o en otros términos agregar el paquete doctrine/doctrine-module como una dependencia de la aplicación, escribimos el siguiente comando:

php composer.phar require doctrine/doctrine-module 2.*

El comando de arriba edita el archivo composer.json, descarga e instala el paquete. Usaremos este comando luego en el capítulo Administración de Bases de Datos con Doctrine cuando comencemos a familiarizarnos con la administración de base de datos.

2.12.4. Paquetes Virtuales

Composer se puede usar para obligar a que algunas funcionalidades estén presentes en nuestro sistema. Ya hemos visto como señalar el requisito «php:^5.6». El «Paquete PHP» es un paquete virtual que representa a PHP mismo. Además, podemos necesitar otras cosas como extensiones de PHP (ver tabla 2.3 más abajo).

Table 2.3. Los Paquetes Virtuales en Composer

Ejemplo de Definición	Descripción
"php":"^5.6"	Se necesita una versión de PHP mayor o igual a 5.6 pero menor a 6.0.
ext-dom, ext-pdo-mysql	Se necesitan la extensiones PHP DOM y PDO MySQL.
lib-openssl	Se necesita la biblioteca OpenSSL.

Podemos usar el comando php composer.phar show --platform para mostrar una lista con los paquetes virtuales disponibles en nuestra computadora.

2.12.5. Composer y el Sistema de Control de Versiones

Si estamos usando un sistema de control de versiones como Git, tendremos curiosidad sobre que debería guardarse en Git: ¿solo el código de nuestra aplicación o el código de nuestra aplicación más todas las dependencias que están en la carpeta APP_DIR/vendor y que instalamos usando Composer?.

En general no es recomendable guardar nuestras dependencias en el control de versiones porque pueden hacer a nuestro repositorio realmente grande y lento de obtener y ramificar. En su lugar debemos guardar el archivo composer.lock en el control de versiones. El archivo composer.lock garantiza que cualquiera pueda instalar las mismas versiones de las dependencias que nosotros tenemos. Esto es útil en equipos de desarrollo que tienen más de un desarrollador porque todos los desarrolladores tendrán el mismo código y se evitarán problemas indeseables relacionados con una mala configuración del entorno.

¿Que pasa si alguna dependencia se declara obsoleta y se borra de Packagist.org?

La posibilidad de que un paquete se remueva es mínima. Todos los paquetes son software libre y de código abierto, la comunidad de usuarios siempre puede restaurar la dependencia incluso si es borrada de Packagist.org. Por cierto el mismo concepto de instalación de dependencias se usa en GNU/Linux (¿recuerdas APT o RPM?), ¿viste algún paquete perdido en tu distribución de GNU/Linux?

Sin embargo hay ocasiones en las que debemos guardar alguna biblioteca de la que depende nuestra aplicación dentro del control de versiones:

Si tenemos que hacer algunos cambios en el código de terceros. Por ejemplo, asumiendo que tenemos que reparar un error en una biblioteca y no podemos esperar que el proveedor los repare por nosotros o no puede reparar el error. En este caso debemos colocar el código de la biblioteca dentro del control de versiones para asegurar que nuestras adaptaciones no se pierdan.
Si hemos escrito un módulo o biblioteca reusable y queremos almacenarlo en la carpeta vendor sin publicarlo en Packagist.org. Como no es posible instalar este código desde Packagist.org lo guardaremos dentro del control de versiones.
Si queremos garantizar que el 100% de una paquete de terceros no se pierda. A pesar de que este riesgo es mínimo, para algunas aplicaciones es crítico ser autónomas y no depender de un paquete que esta disponible en Packagist.org.