Instalando paquetes desde GitHub con Composer

Contenido del curso

Laravel y Base de Datos

Entorno de trabajo y repaso de Laravel

Manejo de tu base de datos con Laravel

La terminal de Laravel

Eventos y tareas de Laravel

Manejo de errores

El corazón de Laravel

Creación de paquetes

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0010:35

Instalando paquetes desde GitHub con Composer

Curso Avanzado de Laravel

Clase 32 de 33

Clase 32 / 33

Recursos

Cuando desarrollas un paquete en Laravel, el paso más importante es demostrar que funciona dentro de una aplicación real. Aquí se aborda cómo limpiar tu proyecto, configurar un repositorio de GitHub como fuente de paquetes en Composer y resolver todos los conflictos que surgen al reemplazar código local por un paquete externo, apoyándote en tests automatizados para validar cada cambio.

¿Cómo preparar tu aplicación antes de instalar el paquete?

Antes de indicarle a Composer que descargue el paquete, es necesario eliminar todos los archivos que ya fueron migrados al paquete [00:22]. Esto incluye:

El modelo Rating que existía en la carpeta app.
La carpeta utils con los traits.
Los eventos que se migraron al paquete.
Las migraciones relacionadas con la tabla de ratings.
El archivo de configuración rating.php, que se publicará posteriormente desde el paquete.

Esta limpieza evita conflictos de clases duplicadas y garantiza que la aplicación dependa exclusivamente del paquete.

¿Cómo configurar un repositorio de GitHub en Composer?

Composer utiliza repositorios como fuentes para descargar paquetes. Por defecto trabaja con Packagist, pero puedes definir repositorios alternativos directamente en tu composer.json [01:02]. Para ello, se declara una key llamada repositories, que es un arreglo de objetos donde especificas el tipo y la URL:

{ "repositories": [ { "type": "vcs", "url": "https://github.com/tu-usuario/tu-repositorio" } ] }

Un detalle fundamental: debes crear un release en tu repositorio de GitHub para que Composer pueda descargar una versión específica del paquete [01:28]. Una vez publicado el release, ejecutas en la terminal:

bash composer require sojeda/rate

El nombre del paquete corresponde al valor declarado en la propiedad name del composer.json del paquete, y debe coincidir con el nombre del repositorio [01:48]. Composer instalará la última versión disponible; en este ejemplo, una versión superior a 2.2, siguiendo las reglas de versionado semántico que se manejan con el operador ^.

¿Cómo resolver conflictos usando TDD después de integrar el paquete?

Al ejecutar los tests después de la instalación, aparecerán múltiples errores porque el proyecto aún contiene referencias a clases locales que ya no existen [02:30]. La estrategia consiste en correr los tests e ir resolviendo cada fallo de forma incremental.

¿Qué referencias se deben actualizar?

Todas las importaciones que apuntaban a App\Rating deben cambiarse al namespace del paquete [03:25]. Esto aplica a:

El archivo de configuración.
Los Resource como RatingResource.
Los controladores, por ejemplo ProductController.
Los tests unitarios, donde también se reemplazan las referencias de eventos y modelos.

Además, los modelos User y Product deben importar los traits del paquete: CanRate y CanBeRated [02:55]. Al implementar interfaces como Ratable y Qualifier, cada modelo debe definir el método name() que retorna la propiedad correspondiente, como $this->name o $this->email [03:15].

¿Cómo afecta la internacionalización a los tests?

El paquete incluye soporte de idiomas (localization), lo que significa que los mensajes de validación se devuelven en el idioma configurado en la aplicación [04:12]. Si los tests esperan mensajes en español pero la aplicación está en inglés, fallarán. La solución es cambiar el idioma en el archivo de configuración app.php a español y asegurar que las aserciones coincidan con el formato exacto, incluyendo mayúsculas y minúsculas.

Después de ajustar las referencias, los namespaces, el idioma y las interfaces, todos los tests pasan correctamente [04:40]. Esto demuestra una de las grandes ventajas de TDD: poder validar la integración completa sin probar manualmente cada endpoint.

Composer permite definir distintos tipos de repositorio, y utilizar GitHub como fuente temporal es una práctica muy útil durante el desarrollo. ¿Ya has creado tu propio paquete? Comparte tu experiencia en los comentarios.

Laravel y Base de Datos

Entorno de trabajo y repaso de Laravel

Qué aprenderás sobre Laravel Avanzado

Instalación de Laravel con Composer

Configuración SQLite y API productos Laravel

Instalación, configuración y uso de Homestead

Instalar Laravel Sanctum

Tipos de autenticación en Laravel

Manejo de tu base de datos con Laravel

API Resource Laravel para JSON preciso

Manejo de relaciones en bases de datos con Laravel

Cómo usar relaciones polimórficas en Laravel

La terminal de Laravel

Comandos personalizados en Laravel con Artisan

Ejecutando comandos desde la API

Programación de tareas

Eventos y tareas de Laravel

Eventos y Listeners en Laravel

Eventos de Eloquent

Queues y jobs en Laravel con driver database

Listeners a jobs con JobQueue en Laravel

Laravel Horizon

Manejo de errores

Cómo capturar y leer errores con la clase Handler

Excepciones personalizadas

Manejo de excepciones HTTP con abort en Laravel

Configuración de logs y channels en Laravel

El corazón de Laravel

Ciclo de vida de una aplicación en Laravel

Qué es el service container de Laravel

¿Cómo funciona un service container?

Service providers: cargar componentes sin instanciar

Creación de paquetes

Cómo crear paquetes Laravel con Composer

Propiedades para manejo de dependencias

Comprende el archivo composer.json

Cómo Composer carga clases automáticamente

Crear mis propios Services Providers

Cómo publicar archivos con Service Provider

Instalando paquetes desde GitHub con Composer

Publicar tu paquete PHP en Packages

Instalando paquetes desde GitHub con Composer