¿Qué es Composer para PHP?
Composer es el gestor de dependencias oficial de PHP, escrito en PHP, que instala y gestiona las librerías de terceros que necesita tu proyecto. Declaras lo que quieres en composer.json y Composer resuelve el árbol de dependencias, descarga todo en vendor/ y genera un autoloader. Descarga los paquetes de Packagist y requiere acceso a la línea de comandos por SSH.
Lo que resuelve es un problema muy concreto y muy antiguo del desarrollo en PHP, porque sin una herramienta como esta tendrías que descargar cada librería a mano, apuntarte qué versión usas de cada una y, lo peor de todo, resolver a mano las dependencias de tus dependencias, es decir, las librerías que a su vez necesitan las librerías que tú instalas.
El corazón de todo esto es un archivo llamado composer.json, donde declaras qué necesita tu proyecto y en qué rango de versiones.
Si vienes del mundo de JavaScript, el paralelo mental es directo: composer.json es a Composer lo que package.json es a npm.
Tú describes lo que quieres y la herramienta se encarga del trabajo sucio de descargar, ordenar y dejar todo listo para usar.
Aquí te explicamos qué es Composer y cómo funciona por dentro, la diferencia entre composer.json y composer.lock, qué papel juega el repositorio central Packagist, en qué se parece y en qué se diferencia de npm y dónde acaba usándose en un proyecto PHP real.
Vamos por partes con cómo funciona Composer por dentro, que es más sencillo de lo que parece.
Tú declaras las dependencias que necesita tu proyecto en el archivo composer.json, y a partir de ahí Composer hace el trabajo pesado: resuelve el árbol de dependencias completo, descarga todo lo necesario en una carpeta llamada vendor/ dentro de tu proyecto y genera un autoloader que carga las clases por ti, así que te permite usar esas librerías sin tener que hacer un require manual de cada archivo PHP.
Composer instala las librerías en local, dentro de tu proyecto, y no de forma global en el servidor.
Esa carpeta vendor/ vive junto a tu código y contiene exactamente las librerías que ese proyecto concreto necesita.
Para que todo esto funcione, tu entorno necesita una versión de PHP compatible con lo que declaras en el proyecto. Un composer.json mínimo, para que te hagas una idea de la estructura básica, tiene esta pinta:
{
"name": "miempresa/mi-proyecto",
"require": {
"php": ">=8.1",
"monolog/monolog": "^3.0"
}
}En ese ejemplo le estamos diciendo a Composer que el proyecto necesita PHP 8.1 o superior y la librería monolog/monolog en su versión 3 o compatible.
Con esto, Composer sabe qué buscar, dónde buscarlo y cómo dejarlo montado en vendor/.
Uno de los puntos que más lía a la gente es la diferencia entre composer.json y composer.lock, y entenderla te ahorra muchos dolores de cabeza al desplegar.
El composer.json declara lo que quieres, normalmente con rangos de versiones flexibles, mientras que el composer.lock congela las versiones exactas que se instalaron en un momento dado.
Esta distinción es la que hace que tu proyecto sea reproducible en cualquier entorno.
Vamos a verlo por partes con cada archivo y su papel:
composer.json: declara tus dependencias en rangos, como por ejemplo
^3.0, que significa "la versión 3 o cualquier compatible superior". Es lo que tú editas y mantienes.composer.lock: guarda las versiones exactas que Composer resolvió e instaló, con el hash de cada paquete. No lo editas a mano, lo genera Composer automaticamente.
Reproducibilidad: cuando despliegas en tu servidor, Composer lee el
composer.locke instala exactamente las mismas versiones que tenías en desarrollo, no las últimas disponibles, así evitas el clásico "en mi máquina funcionaba".
Por eso el composer.lock debe ir bajo control de versiones junto a tu código.
Si versionas tu proyecto con el sistema de control de versiones Git, ese archivo tiene que estar dentro del repositorio, porque es lo que garantiza que tu servidor de producción y tu entorno de desarrollo instalen exactamente lo mismo. Sin él, cada composer install podría traerte versiones distintas y pueden aparecer bugs que no sabes de dónde salen.
Llegamos al repositorio central Packagist, donde se guardan los paquetes PHP que puedes instalar con Composer.
Funciona como una especie de directorio central de librerías: cuando en tu composer.json pides monolog/monolog, Composer va a Packagist, encuentra el paquete, mira qué versiones hay disponibles y descarga la que encaje con lo que pediste.
Packagist es a Composer lo que npmjs.com es a npm.
Una de las ventajas que más agradeces en el día a día es el autoloading PSR-4.
En lugar de tener que hacer un require manual de cada archivo de cada librería, Composer genera un autoloader que carga las clases automáticamente cuando las usas.
Incluyes un solo archivo, el vendor/autoload.php, y a partir de ahí todas las clases de todas tus dependencias están disponibles sin más trámite.
Aquí entra la ventaja del aislamiento por proyecto: al instalar las librerías en local dentro de cada proyecto, en vez de global en el servidor, evitas los conflictos de versiones entre proyectos distintos.
Imagina que tienes un proyecto antiguo que depende de la versión 2 de una librería y otro proyecto nuevo que necesita la versión 3 de esa misma librería. Con una instalación global tendrías un problema serio, porque solo puede haber una versión instalada.
Con Composer no pasa nada, cada proyecto lleva su propia vendor/ con la versión que le toca.
Si te preguntas por Composer vs npm y en qué se parecen, la respuesta corta es que hacen lo mismo pero cada uno en su mundo: los dos gestionan dependencias, resuelven el árbol de librerías y automatizan la descarga.
La diferencia es el ecosistema, porque Composer es para PHP y npm es para JavaScript y Node.js. No compiten entre ellos, cada uno resuelve el mismo problema en su lenguaje.
Si miramos las piezas una al lado de la otra, las similitudes son evidentes:
Archivo de declaración: Composer usa
composer.jsony npm usapackage.json. En ambos declaras qué necesita tu proyecto y en qué versiones.Repositorio central: Composer descarga de Packagist y npm descarga de npmjs.com. Los dos son el catálogo público de paquetes de su lenguaje.
Lockfile: los dos generan un archivo que congela versiones exactas, el
composer.locken Composer y elpackage-lock.jsonen npm, para que el proyecto sea reproducible.
Si ya has trabajado con npm, Composer te va a resultar familiar desde el primer minuto, porque la filosofía es prácticamente idéntica. Lo que cambia son los nombres de los comandos y el ecosistema de paquetes que hay detrás de cada uno.
Vamos a lo importante, que es dónde y cómo se usa Composer en un proyecto real.
Composer no es una herramienta opcional para proyectos modernos en PHP, es la base sobre la que se construye casi todo, porque los frameworks y CMS actuales dependen de Composer para gestionar su stack de librerías.
El framework Laravel se apoya en Composer para todo su ecosistema, y October CMS, que está construido sobre Laravel, hace exactamente lo mismo. Si trabajas con cualquiera de ellos, estás usando Composer aunque no seas del todo consciente.
Aquí está el detalle que condiciona dónde puedes usarlo: Composer necesita acceso a la línea de comandos, es decir, una terminal por SSH. No es una herramienta que uses desde un panel gráfico con botones, sino desde la consola del servidor. Esto deja fuera al hosting compartido tradicional, que por seguridad no ofrece acceso SSH.
Si tu proyecto en PHP necesita Composer, el camino natural es un plan que sí incluya terminal con acceso SSH.
Nuestro hosting Elástico con acceso SSH, cPanel y Composer trae la herramienta lista para usar, junto con Git, WP-CLI y el resto de utilidades de línea de comandos que necesita cualquier flujo de desarrollo serio en PHP, sin tener que administrar un servidor VPS completo.
Si en cambio tu stack va más por el lado de Node.js, Python o Ruby, con sus propios gestores de dependencias como npm, PIP o RubyGems, tenemos el hosting para desarrolladores, también con acceso SSH completo.
Y si prefieres un control total del entorno, un servidor VPS te da libertad absoluta; contacta con nuestro departamento comercial y te ayudamos a dimensionarlo según lo que vayas a desplegar de verdad.
Álvaro Fontela
Consultor WordPress, además de CEO y cofundador de Raiola Networks. Autor del libro "Curso Práctico de WordPress" y speaker en congresos de marketing digital.
Autor
¿Te gusta nuestro contenido?
Si quieres ser el primero en leer nuestro contenido y enterarte de nuestras noticias.
HOSTING SSD desde 8,95€
Haz clic aquí¿Te ayudamos?
Escríbenos si tienes dudas o necesitas una solución específica
Categorías
Destacados