Trabajando con paquetes Composer en local

Introducción

Si has estado trabajando con 💡 Symfony Framework PHP de alto nivel orientado a componentes. Muy usado en proyectos empresariales y APIs REST. Más info → o PHP y 💡 Composer Gestor de dependencias para PHP. Permite instalar y gestionar paquetes externos desde packagist.org mediante un fichero composer.json. Más info → , seguramente alguna vez has trabajado con 💡 Bundles Plugins o módulos de Symfony que encapsulan funcionalidad reutilizable: controladores, servicios, configuración, etc. Es la forma estándar de distribuir código entre proyectos Symfony. o con 💡 packages Librería o conjunto de código reutilizable que se instala vía Composer. Se publican en Packagist y se declaran como dependencias en el fichero composer.json. .

Muchas veces si tú estás desarrollando un package nuevo, comenzarías en local. Si en tu proyecto principal u otro proyecto implementas este package, de alguna forma debes hacer el require y poder ir trabajando localmente a modo de prueba/error para ir avanzando en tu desarrollo.

Pues a continuación te explico cómo poder trabajar de esta manera.

Esquema de funcionamiento de Composer local.

Fichero composer.json

La magia ocurre en este fichero. Ábrelo y, si no tienes la matriz de repositorios, tendrás que agregarla:

"repositories": [
    {
        "type": "path",
        "url": "/home/domin/Projects/my-package",
        "options": {
            "symlink": true
        }
    }
],

Vamos a ver que es esto, qué hace y pa qué sirve. Aquí le indicamos a Composer que cuando vaya a buscar el package a 💡 Packagist El repositorio público principal de paquetes PHP. Composer lo consulta por defecto al hacer composer require. Más info → , por ejemplo domin/my-package, se va a encontrar el package en cuestión en este path:

Mediante el type = path le indicamos que es una ruta de fichero local.
En el valor de la url le indicamos el path físico, la ruta absoluta al package.
En las options, poniendo symlink a true, le decimos a Composer que haga un enlace simbólico al vendor, para que cualquier cambio que hagamos en el package se vea reflejado automáticamente en el proyecto principal. Si no hiciéramos esto, en cada actualización que hiciésemos del package tendríamos que hacer un nuevo composer require o composer update.

Ahora, para poder instalar el package hacemos un:

composer require domin/my-package @dev

Y EA, nuestro package estará instalado usando como fuente el directorio que hemos seteado.

También destacar que usamos @dev porque, al trabajar en local, es probable que tu paquete aún no tenga etiquetas de versiones estables. Esto le dice a Composer que acepte la versión de desarrollo.

y EA, eso es todo amigos, Arribeerderci! 🍻